Using the OIDC Discovery flow is difficult

The OIDC discovery flow implementation of the config builder feels like a leaky abstraction.

When used from the dependency injection / ServiceCollection extension methods, it requires the application to build the config object before other types are instantiated (which ideally it should not need to worry about when using an inversion of control containter pattern).

When used from the fluent client builder code it requires the application code to become familiar with implementation details like the IHttpClientFactory and IMessageHandlerFactory that would ideally not be exposed.

The TendukeConfig object is most likely only used by the SDK and not something the application code interacts with outside of initializing the SDK. Requiring the config to be fully initialized before interacting with the SDK initialization code makes this flow, in particular, more complex than is ideal.

For the fluent builder, it could be possible to roll the TendukeConfigurationBuilder interactions into the commands to initialize the ILicenseCheckoutClient (and not exposing the requirements for the IHttpClientFactory and IMessageHandlerFactory).

For the ServiceCollection there could be a way to tie the two pieces together such that the config builder was available to the factory method for the ILicenseCheckoutClient.

The intention of providing the OIDC discovery flow is to reduce complexity for the client application (by removing the need to manage the URLs for the various OIDC endpoint in configuration). This issue is to record that using the OIDC discovery flow is more complex than not using it (from an SDK code interaction point of view).