lazy load platform configuration in sdk

[strantalis]

The Problem Today the way the sdk works is it tries to make a call to fetch the platform configuration. The SDK greedily builds the clients, and doesn't discriminate on which clients you want/need.

https://github.com/opentdf/platform/blob/32c09c3993bee369401537a9370478dc519ec415/sdk/sdk.go#L118-L141

This is problematic when trying to leverage the sdk with client credentials in a monolith because our auth interceptor for the sdk requires the token endpoint. The change I am proposing here is to build on what @jakedoublev started when exposing more platform configuration for the cli.

One Approach Other approaches are welcome -- here is one approach: We would restructure the type PlatformConfiguration map[string]interface{} to be a struct

type PlatformConfiguration struct {
  config  map[string]any
  wellknownService wellknownconfiguration.WellKnownServiceClient
}

This would then allow us to pass the PlatformConfiguration into our internal auth interceptors that we maintain. Allowing us to only make that first configuration call on the very first request for an access token.

Acceptance Criteria:

• only load platform configuration when needed and don't block sdk initialization
• documentation updates
• add tests to show we can pass sdk_config with client id and secret even in ipc mode.

[jakedoublev]

Something interesting we could think about here is how we want to expose this PlatformConfiguration to SDK consumers.

The current implementation places the exposed PlatformConfiguration on the embedded internal config (lower case) SDK struct field: https://github.com/opentdf/platform/blob/main/sdk/sdk.go#L55

This exposes it as a map[string]interface{} to consumers (with the contract guaranteed through accessor methods alone rather than concrete structure), and makes it visible within intellisense (see below) and at compile time, but not in the generated documentation (see below 2).

Perhaps we could improve this documentation difference during this effort.

[strantalis]

I think we should fix this and move it up to the SDK struct or even embed it into that struct so the methods look like they hang off of SDK maybe.

type SDK struct {
  Platformconfiguration
}

[elizabethhealy]

delaying until config service work is further along as it may impact/overwrite whatever is done here