[flagd] ContextEnrichment for inprocess improvements by extracting logic onto the channelmonitor

[aepfli]

Currently our Context Enrichment is handled here:

https://github.com/open-feature/java-sdk-contrib/blob/122119bcbb4fe8e9bfe0de42feafaa54625c050f/providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/resolver/process/storage/connector/grpc/GrpcStreamConnector.java#L107-L124

We always try to fetch the metadata before we reestablish a connection, during our stream listening logic.

This might be a little bit tricky, as we are always relying on the same process, and if eg. the timeline exceeds etc. the whole process breaks.

The question is how important it is to fetch this metadata, as we could theoretically also do this unary call when the channel state changes to READY, instead of always during the loop.

This would decouple our sync from the metadata, and might increase our robustness.

WDYT?

cc: @guidobrei @toddbaert @beeme1mr @alexandraoberaigner @chrfwow

[toddbaert]

Another option I was thinking about is that we could deprecate this RPC entirely, and add it to the content of the sync itself... so instead of the SyncFlagsResponse just having a flagConfiguration field, it could also have a syncMetadata field (or perhaps we could rename it something more in-line with its usage, like staticContext or something)...

[aepfli]

agree this makes sense, and we could get rid of connection status tracking within the sdk and add a connection indicator as we do for the EventStream - this way, we do not need to keep the connection state within the sdk, but can get this information from the outside