feat(flagd): Add in-process evaluator

[aepfli]

With these changes, we're adding in-process evaluation to the python flagd sdk. The whole e2e test-harness suite is passing, except the cases for unix socket and targetURI which are not implemented

[codecov]

Codecov Report

Attention: Patch coverage is 95.00000% with 6 lines in your changes missing coverage. Please review.

Project coverage is 94.13%. Comparing base (80cff25) to head (992bc37).

Files with missing lines	Patch %	Lines
.../flagd/resolvers/process/connector/grpc_watcher.py	94.17%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #104      +/-   ##
==========================================
+ Coverage   93.91%   94.13%   +0.21%     
==========================================
  Files          15       17       +2     
  Lines         789      903     +114     
==========================================
+ Hits          741      850     +109     
- Misses         48       53       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aepfli]

no more e2e tests are skipped 🎉

[toddbaert]

no more e2e tests are skipped 🎉

LEEEETSS GOOOOO!

[toddbaert]

The only issue I found is that the enum for the resolver should be rpc | in-process instead of grpc | in-process, I pushed an update for this (code, docs, and tests).

[aepfli]

I can, and gladly will split it up into 4 parts again:

1. proto buff generation build(flagd): auto generate proto files from schema #109
2. events for RPC feat(flagd-rpc)!: add events for rpc mode, some breaking config fixes #108
3. caching for RPC feat(flagd-rpc): add caching  #110 (depends on 1 and 2)
4. sync implementation with config adaptions (this will still stay big, as it is a new feature overall) - this pr (depends on 3)

The config adaptations (Ms and seconds) also make sense because this syncs the behavior of environment flags for all providers. Java is in MS and is, IMHO, the most advanced provider for flags; hence, we should adhere to its environment variables usage and values, or else we have way more things to change. We use the same environment variables to make it easy to configure multiple providers with the same environment variables. This provider did not reach version 1, making it a better target than Java.

The same applies to the resolver's name. Everywhere else, it is named RPC; here, we do have GRPC. We should normalize this for consistency and easier maintenance in the long run.

A good thing is that all the features implemented fulfill the test-harness gherkin files. We're compliant with the expectations of flagd for a provider - confidence we did not have before. I also suggest not looking for perfect code; this confidence allows us to iterate faster and ship improvements confidently.

[beeme1mr]

Thanks @aepfli! That should make it easier to review and make our release notes more accurate.

[toddbaert]

The config adaptations (Ms and seconds) also make sense because this syncs the behavior of environment flags for all providers. Java is in MS and is, IMHO, the most advanced provider for flags; hence, we should adhere to its environment variables usage and values, or else we have way more things to change. We use the same environment variables to make it easy to configure multiple providers with the same environment variables. This provider did not reach version 1, making it a better target than Java.

The same applies to the resolver's name. Everywhere else, it is named RPC; here, we do have GRPC. We should normalize this for consistency and for easier maintenance in the long run.

Besides the fact this is what Java does, these are actually in the spec for flagd providers, and are important for interop with the Operator.

But it sounds like we have a plan for moving forward! Feel free to link your other PRs to this one and close this one whenever @aepfli

[aepfli]

But it sounds like we have a plan for moving forward! Feel free to link your other PRs to this one and close this one whenever @aepfli

this one is the last in the chain, i will update it and mark it as soon as we are ready

[aepfli]

I merged all the previous work, and updated the implementation to match our latest findings regarding grpc. - there is room for improvements, eg. removing duplication between rpc and in-process for grpc connection etc. but i do think, this is something we can do in another step.

should i open a new pull request, or will we continue from here?

[beeme1mr]

Will the file mode changes come later?

[beeme1mr]

Is info level the right fit here? It appears to be more a debug message.

[beeme1mr]

How many cases are not covered yet?

[aepfli]

Targeturi, unixsockets