FFL-1460 Update Flags SDK to evaluate feature flags synchronously

[yugisu-flux]

What does this PR do?

This PR updates the Flags SDK to evaluate feature flags synchronously.

After these changes, the Flags package API surface should look like the following:

DatadogFlags

• enable() - Initializes the general Flags SDK
• getClient() - Retrieves a client by (an optional) name. The recommended way to get client instances. Clients are actually initialized by setEvaluationContext.
• Update example applications to feature two steps of using the Flags SDK: init blocking rendering and sync flag evaluations

FlagsClient

• setEvaluationContext() - Sets evaluation context and fetches flag values from the native SDKs. Should be called before flag evaluations, similarly to the mobile SDKs and the web SDK
• getDetails() typed methods
• getValue() typed methods

Implementation details

The FlagsClient architecture has been changed from being a thin bridge/wrapper for native getDetails calls to a layer that fetches ALL flags from the native SDK and stores it on the JS side. Individual flag values are synchronously served from this internal cached state via e.g. getBooleanValue method. Flag evaluations are tracked internally by calling an exposed native nativeFlags.trackEvaluation method.

This way, the native SDKs serve a purpose of fetching and persisting flag configurations, and the JavaScript layer tries to stay as thin as possible, while doing the necessary work for sync evals.

The disadvantages to this approach are: implementing some new features like flags polling or local evaluations would be extra work, due to the duplication of cache between native and RN; iOS and Android SDK repositories are modified to accommodate for these changes.

The other approaches that were evaluated during the implementation

Bump minimum RN version for the Flags SDK specifically, and make get*Details calls synchronous by leveraging JSI.

• Pros: the React Native wrapper becomes extremely thin, future complex features are handled automatically due to JavaScript serving as a thin bridge
• Cons: limiting customer base, requirement to bump minimum RN version to 0.74-ish (from 0.63)

Drop the dependency on native Flags SDKs, use the JavaScript core from https://github.com/DataDog/openfeature-js-client.

• Pros: JS-native wrapper, no need to maintain a complex wrapper
• Cons: no access to native capabilities, need to rewrite the JavaScript core as it very much depends on browser APIs (through the web RUM SDK)

Motivation

Flag evaluations should be synchronous. More details here: https://datadoghq.atlassian.net/browse/FFL-1460

The changes in this PR have been developed jointly with:

• iOS PR: FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals  dd-sdk-ios#2604
• Android PR: FFL-1460 FlagsClient changes to accommodate Flags RN SDK sync flag evals dd-sdk-android#3049

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)
• If this PR is auto-generated, please make sure also to manually update the code related to the change

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 2cc11d6 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}