[FEATURE] Normalize selector handling across sync, evaluation, and OFREP services

[aepfli]

Requirements

Problem

Currently, we have inconsistent handling of selectors across different flagd services:

• Sync Service (flagd/pkg/service/flag-sync/handler.go:34): Uses req.GetSelector() from the request body
• Evaluation Service: Uses flagd-selector header
• OFREP Service: Uses flagd-selector header

This inconsistency can lead to confusion for users and makes the API surface less predictable.

Proposal

Normalize selector handling across all services by:

1. Preferred approach: Use the flagd-selector header as the primary method for all services
2. Backward compatibility: For the sync service, continue to accept selector in the request body as a fallback for a deprecation period

Implementation Strategy

1. Update sync service to check for flagd-selector header first
2. Fall back to request body selector field if header is not present
3. Log deprecation warning when using request body selector
4. Document the change and migration path
5. Remove request body selector support in a future major version (e.g., v2.0.0)

Benefits

• Consistent API across all flagd services
• Easier to understand and use for developers
• Aligns with common patterns for query/filter parameters in gRPC metadata

Breaking Changes

None initially (backward compatible), but request body selector would be removed in a future major release.

Additional Context

The sync service currently processes the selector at:

selectorExpression := req.GetSelector()
selector := store.NewSelector(selectorExpression)

This should be updated to prioritize metadata/header values while maintaining backward compatibility.

[aepfli]

Out of curiosity I assigned Copilot to this ticket, to see what happens. We still need to triage this ticket

[toddbaert]

gRPC metadata/headers are implemented as HTTP2 headers (binary, compressible) things will never be 100% consistent here, but I do agree it's a step in the right direction, so I support this idea.

[toddbaert]

@guidobrei and I did a bit of searching, and it seems at least envoy doesn't even distinguish between HTTP1.1/2 much in it's header manipulation features, so adding this will greatly improve our "cloud-nativeness" I think (ie: people will be able to manipulate things in the infra more easily).