Add Events and async client

[vahidlazio]

• Add basics for adding the events
• Add extension to convert the client to the async client.

To do some actions after provider is ready:

CoroutineScope(Dispatchers.IO).launch {
        awaitProviderReady()
        // now provider is ready, read the properties
    }

The usage will be something like:

openFeatureClient
.toAsync()
.observeStringValue(key, default)
.collect { 
// do something with boolean
}

in the compose world will be:

val myStringProperty = openFeatureClient
.toAsync()
.observeStringValue(key, default)
.collectAsState()

we can update the implementation to limit the value emissions only for when the provider is initialised and ready to not emit the default value if the provider is not ready.

[fabriziodemaria]

Still unfamiliar with the details of Flow, but added some generic comments

[fabriziodemaria]

Can we have a "observeProviderState" that listens to any Provider State event?

[vahidlazio]

we have 2 functions one observeProviderReady and another one a suspending function awaitProviderReady(). added to the description of the PR.

[vahidlazio]

i removed the secondary way and now we have one way as helper functions to listen for providerReady

CoroutineScope(Dispatchers.IO).launch {
        awaitProviderReady()
        // now provider is ready, read the properties
    }

[fabriziodemaria]

Should we name this to something "state" specific, e.g. ProviderStateEvents?

[vahidlazio]

i would argue this can be used to any sort of event from the provider and IMO it's not always about the provider state.

[fabriziodemaria]

Similar comment above: let's extend this to support any ProviderStateEvent type?

[vahidlazio]

this is just a helper function for provider ready. the design already allows listening for all the events like:

EventHandler.eventsObserver()
.observe<OpenFeatureEvents>()
.collect {
// do something with the event
}

[fabriziodemaria]

I wonder if we should keep "suspend" in the interface towards the Provider, and only remove "suspend" from the OpenFeature user-facing API setProvider

[vahidlazio]

i think it makes sense that now we have the shutdown function we move the responsibility of having scopes and suspending in the provider side. but we can further discuss this.

[fabriziodemaria]

I wonder is the provider is not ready after ProviderConfigurationChanged as well, as I think that's when a new EvaluationContext is set and the Provider starts fetching the new values from backend

[vahidlazio]

like ShutDownCompleted? i believe the signal of shutdown is coming from the Provider and it's signaling that the provider is shut down.

[fabriziodemaria]

Would be great to curate the PR description a bit more, since this is probably the place where all reviews will happen.
A few ideas:

• Can we elaborate more on the toAsync() function? Is this necessary if we expect users to always use our async APIs anyway (do we expect that?))
• Perhaps adding a few more code examples on how to wait for ProviderReady and just get a flag value after that (without observing the flag value via "Flow")