feat!: Make the eventing provider specific instead of being singleton

[vahidlazio]

This PR

• Make the eventing provider specific instead of being singleton

[fabriziodemaria]

Overall, I think there is an opportunity to take inspiration from the Java SDK setup (which should also adhere very well to the Specs): https://github.com/open-feature/java-sdk/tree/main

[fabriziodemaria]

Let's remove this too. I guess this function would just return right away if no provider is set?

[nicklasl]

Hm... If no provider is set then getProvider() returns null and I assume requireNotNull will throw an exception. This is not great IMO.

Ideally this suspending function would just hang until a provider is set on OpenFeatureAPI and become ready. However I don't know how to solve that. Ideas?

[nicklasl]

Is it completely crazy to setup a flow where we continously poll getProvider() until one becomes available?

[vahidlazio]

i thought about polling .. but isn't it too much maybe?

[vahidlazio]

we have 5 options :
1- not have this function at all.
2- never return from this suspending if no provider set (bad because you won't know why you don't get out of the await function)
3- exception with correct message so you know you ask for this function early
4- poll until provider is set
5- return if provider is null (bad because returning implies the provider is ready which is not in this case)

IMO, we need to choose between option 4 or 3. I chose the option 3 but if that's violating the not throwing exception rule. I can try the polling thing.

[beeme1mr]

I may be missing some of the context here but would it be possible to return he no-op provider?

[vahidlazio]

@beeme1mr we updated the extension to be like following instead of waiting for provider in a different line and we are adding the setProviderAndAwaitReady.

suspend fun OpenFeatureAPI.setProviderAndAwaitReady(
    provider: FeatureProvider,
    dispatcher: CoroutineDispatcher
) {
    OpenFeatureAPI.setProvider(provider)
    provider.awaitReady(dispatcher)
}

[nicklasl]

nit: I would expect an interface such as this to have a getStatus(): Status function.

[nicklasl]

Need to put some proper effort in documenting the API's in this file but I think this can go in a separate PR.

[beeme1mr]

Can this be the in-memory provider? We started adding those in to other SDKs. It can be used in tests or for basic use cases.

[toddbaert]

In most SDKs there's a testing provider (or a few) that have more testing features related to testing the SDK itself (such as throwing on init to test init logic, etc). That seems more like what this is.

The in-memory provider is mostly for outsiders to test things. I think that's a separate issue.

[beeme1mr]

This is imported twice.

[vahidlazio]

will fix in the next PR.

[toddbaert]

I'm not much of a Kotlin dev, so I could be missing something, but this looks right to me.

I think this will make implementing named providers more simple.