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

[aepfli]

Currently our Context Enrichment is handled here:

java-sdk-contrib/providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/resolver/process/storage/connector/grpc/GrpcStreamConnector.java

Lines 107 to 124 in 122119b

	Exception metadataException = null;
	log.debug("Initializing sync stream request");
	final GetMetadataRequest.Builder metadataRequest = GetMetadataRequest.newBuilder();
	GetMetadataResponse metadataResponse = GetMetadataResponse.getDefaultInstance();
	try (CancellableContext context = Context.current().withCancellation()) {
	try {
	metadataResponse = grpcConnector.getResolver().getMetadata(metadataRequest.build());
	} catch (Exception e) {
	// the chances this call fails but the syncRequest does not are slim
	// it could be that the server doesn't implement this RPC
	// instead of logging and throwing here, retain the exception and handle in the
	// stream logic below
	metadataException = e;
	log.debug("Metadata exception: {}", e.getMessage(), e);
	}

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