Sync.proto support in flagd

[toddbaert]

Background

We define 2 protos relevant to flagd: evaluation.proto and sync.proto
flagd doesn't currently support the sync.proto; it only supports evaluation.proto.
This means flagd can evaluate flags, but can't simply deliver flag definitions to clients interested in doing their own flag evaluation (this is how in-process providers work).

Practically, this means that if you want to use an in-process provider, you must implement some compliant gRPC server or use the OpenFeature Operator which has it's own implementation (see relevant github discussion).

Proposal

Add sync.proto support to flagd:

• add an sync.proto implementation to flagd
• clients can connect, and supply a selector, indicating which sync source they are interested in, or omit one to get an aggregation of all flags (the same aggregation the evaluation.proto implementation uses)
• flagd would propagate changes to any connected consumer using the SyncFlagsResponse if a relevant source changes

Questions

• should sync.proto run on the same port?
  • consider security concerns since this proto expose the entire flag configuration
• should sync.proto be implemented as raw gRPC or using connect (gRPC + HTTP/1.1)?
  • this has implications on the possibility to serve web clients

[Kavindu-Dodan]

Given we are expanding and solidifying support for in-process providers, I think this is a good proposal.

I checked the current flagd implementation and came up with the following high level diagram,

And I have the following basis for my proposal,

• We shouldn't change the flag sync mechanism of flagd (restrict sync sources at startup in contrast to how flagd-proxy behaves)
• flagd store should be enhanced to have change eventing (we already have a simpler one for cache busting for rpc evaluators)
• Introduce a connector layer to store, exposing scoped (selector specific) or non scoped (all) flags using sync protocol

should sync.proto run on the same port?

+1 for separate ports

should sync.proto be implemented as raw gRPC or using connect (gRPC + HTTP/1.1)?

+1 for connect to fulfill both client and server requirements

[Kavindu-Dodan]

Implementation will be tracked through issue #1230