feat: Adapt the client and the integration tests to the KinD based CAPI

[ZPascal]

The integration tests fail against the current CAPI deployed on KinD (see #1381). This PR fixes what broke for 5.x.x.

Client

• Bits uploads now always send a resources field. CAPI otherwise rejects them (CF-AppBitsUploadInvalid / missing :resources).
  • v3 packages: the resources part is always added, as JSON, and is [] when there are no matched resources.
  • v2 apps: the nginx upload module can drop the form field, so when there are no matched resources I also add resources=[] as a query parameter. Cloud Controller accepts it there, but only an empty list fits into a URL, so a non-empty list stays a form field only.
• LdapConfiguration and SamlConfiguration got a caCertificates list for the CA certificates of the identity provider.

Integration tests

• At startup, the tests now reserve the TCP ports that NameFactory hands out (1025 to the maximum) on the default-tcp router group. The TCP route tests no longer depend on the test order or on the default port range of the deployment. Setting SKIP_TCP_ROUTING_TESTS skips this. If there is no default-tcp group, it only logs a warning.
• The routing client for this uses its own token provider, because the shared one depends on the cleaner, which now depends on this bean.

Testing

• Unit tests of cloudfoundry-client, cloudfoundry-client-reactor and cloudfoundry-operations pass on JDK 11
• I added tests for the v2 upload with and without async, and extended the v3 upload test to check the resources part.
• The integration tests were made functional as part of this PR using a current CAPI release and tested here (main branch)

Connected PR

#1381

[Kehrlann]

I think we should not make the routerGroupPorts a bean.

[Kehrlann]

Still a bit unsure what we're doing with this bean. Are we making sure that ports can be reserved on the default group in the first place, before we do anything else? And this is only so that the reservable range from the CF config is overridden by the config we have in our tests, correct?

This follows the established pattern, which, unfortunately, is hacky and convoluted (e.g. @Bean(initMethod = "block") Mono<...> is bad). Let's try and make it cleaner.

I don't see why the CC Cleaner depends on this though - is it only to avoid doing an initial cleanup if the routing is not possible?

If that's just it, I'm ok paying the price of the initial cleanup just for clarity:

1. We can re-use the existing routing client
2. We can use ApplicationContextRunner and make stuff less crazy

e.g.

@Bean
@ConditionalOnExpression("!'true'.equalsIgnoreCase(systemEnvironment['SKIP_TCP_ROUTING_TESTS'])")
ApplicationRunner setReservablePort(RoutingClient routingClient) {
    // Ensure that the default-router-group reservable port range matches whatever our tests use.
    return args -> {
        var defaultGroup = routingClient
                .routerGroups()
                .list(ListRouterGroupsRequest.builder().build())
                .flatMapIterable(ListRouterGroupsResponse::getRouterGroups)
                .filter(group -> "default-tcp".equals(group.getName())).blockFirst();

        if (defaultGroup == null) {
            throw new RuntimeException("No default-tcp router group, TCP route tests will fail. " +
                                   "Set SKIP_TCP_ROUTING_TESTS=true to skip TCP routing tests entirely.");
        }

        routingClient
                .routerGroups()
                .update(
                        UpdateRouterGroupRequest.builder()
                                .reservablePorts(
                                        RandomNameFactory.PORT_RANGE)
                                .routerGroupId(defaultGroup.getRouterGroupId())
                                .build()).block();
    };
}

In the longer run, it'd be much, much better to move the CF cleaner to a similar pattern (but not as part of this PR)