[CHORE] Backfill ADR for the Sync API

[cupofcat]

• [ ] Define and publish relationship and common definition strategy for sync.proto and OF SDK
  • mention key difference in usage between evaluation API (evaluation.proto)
  • implications on client vs server-side evaluation
  • security implications (rules, PII, etc)

[tangenti]

Once we have the backfill ADR for sync API, we should have better understanding of what it's missing and what is no longer needed in sync API.

After the change of allowing providing flags as a list, we should consider extending the sync API to better handle the requests from flagd provider, in particular when the selector provided will result in flags with duplicate keys. Options to consider

1. Add an option in the request to specify the behavior in such case - pick any / fail.
2. Add error along with the response to indicate such issues.

[beeme1mr]

I believe this ADR should address this issue.

https://github.com/open-feature/flagd/blob/main/docs/architecture-decisions/multiple-sync-sources.md

[tangenti]

I believe this ADR should address this issue.

https://github.com/open-feature/flagd/blob/main/docs/architecture-decisions/multiple-sync-sources.md

IIUC this task will be more about the gRPC sync service?

GetMetadata was deprecated, and then I remember there was a discussion for the state/status in the response. It would be nice to align on the goal and the focus of this gRPC service.

[toddbaert]

I believe this ADR should address this issue.

https://github.com/open-feature/flagd/blob/main/docs/architecture-decisions/multiple-sync-sources.md

No I don't think so @beeme1mr , this is to understand the sync.proto as a means of facilitating (mostly) server-side in-process evaluation... essentially why somebody would use sync.proto + in-process instead of RPC.