Share containers in DevServices for Keycloak

[sberyozkin]

This PR adds the code (similarly to what is done in KafkaClient) for Keycloak DevServices DevMode containers to be optionally shared.

For now I've decided to avoid a serviceName property since for Keycloak it is a realmName which is a key identifier so I think it is fine for a label value.

CC @sebastienblanc

[stuartwdouglas]

For the record only as I've removed it from the description:
Sergey:

@stuartwdouglas Most of this code is about a label based container discovery (I copied it from KafkaClient) - something Sebastien also asked about (using the same container when multiple Quarkus applications are started).

At the very end of the PR changes you can see the test code - specifically note how the access tokens are acquired. What ahpoenshappens there is that when that test is launched DevServices binds to the existing container started by the test factory. This may be a total nonsense, but I'd like to understand what are the alternatives.

Stuart:

I don't really think we should be doing this. DevServices is supposed to be a replacement for KeycloakTestResourceLifecycleManager. If you are using KeycloakTestResourceLifecycleManager then DevServices should be disabled (in fact we should add a facility to automatically allow this).

At the moment container based discovery is only intended for use in dev mode, it is intended for tests to get their own isolated instance that is configured correctly for the tests.

[stuartwdouglas]

I would rather keep it consistent with regard to using serviceName rather than realmName to match all the other services.

[sberyozkin]

@stuartwdouglas

I would rather keep it consistent with regard to using serviceName rather than realmName to match all the other services.

This is done