We used to experience a lot of flakiness due to the keycloak devservice starting, but doing so with errors and therefore causing all tests that were running with keycloak to emit 'IllegalArgument accessToken cannot be null'. The start-up errors were a bit cryptic and unspecific and looked like this:

2023-11-06 08:01:14,552 INFO [tc.doc.xxx.0.1] (build-7) Container ourrepomirror.docker/keycloak/keycloak:22.0.1 started in PT3M46.054007184S
2023-11-06 08:01:18,712 ERROR [io.qua.oid.dep.dev.key.KeycloakDevServicesProcessor] (build-7) Admin token can not be acquired: null
2023-11-06 08:01:19,655 ERROR [io.qua.oid.dep.dev.key.KeycloakDevServicesProcessor] (build-7) Realm rdpro can not be created 401 - Unauthorized
2023-11-06 08:01:27,690 ERROR [io.qua.oid.dep.dev.key.KeycloakDevServicesProcessor] (build-7) Realm rdpro can not be created: Keycloak server is not available: Retries exhausted : 5 attempts against 1699257689687/1699257689656 expiration
2023-11-06 08:01:27,699 INFO [io.qua.oid.dep.dev.key.KeycloakDevServicesProcessor] (build-7) Dev Services for Keycloak started.

It took us some time to realize that `Admin token can not be acquired: null` actually meant 'Acquiring the Admin token timed out' and that 'null' was the TimeoutException's message. Thankfully the property `quarkus.oidc.devui.web-client-timeout` exists to increase this timeout, though it is somewhat oddly named ("devui"? Should these properties be split into two?).

I tried to improve the situation by making errors actually print the exception and stacktrace, and by improving the user feedback a bit.