feat: implemented LRU caching for flagd provider

[bacherfl]

Closes #37

This PR implements standard caching functionality for the flagd provider. The configuration is done via the following env vars:

| Caching                      | FLAGD_CACHE                    | string  |           |     LRU       |
| Maximum cache size           | FLAGD_MAX_CACHE_SIZE           | number  | 10        |               |
| Maximum event stream retries | FLAGD_MAX_EVENT_STREAM_RETRIES | number  | 3         |               |

When caching is enabled, the flagd provider will establish an EventStream with the flagd server via grpc, and listen for configuration_change events. When such an event is received for a flag that has already been cached previously, that flag will be removed from the cache. When retrieving the value of a feature flag, the value will be cached if the Reason of the resolution is set to STATIC.

Note: The imported version of the OF dotnet-sdk is set to 0.5 - Since this version does not yet include the configuration_change event type, or the STATIC reason type for the resolutionDetails, it might be worth to consider bumping the version of the imported dotnet-sdk as a follow up task.

Note: Since the Event Stream is opened in a background task, I was not quite sure how to best verify in the Unit tests that things like the removal of a cached item were properly called by the provider. Coming from Golang, I was missing something like require.Eventually(t, len(mockCache.DeleteCalls) == 1). I tried to resemble that behaviour by creating an AutoResetEvent that gets set in the mock implementation of the method I would like to ensure it was called. Then, using Assert.True(_autoResetEvent.WaitOne()) I waited for the event to be triggered. This solution does seem to work, but if there is a better approach to this in C# I appreciate every input from the reviewers of this PR

[toddbaert]

Note: Since the Event Stream is opened in a background task, I was not quite sure how to best verify in the Unit tests that things like the removal of a cached item were properly called by the provider. Coming from Golang, I was missing something like require.Eventually(t, len(mockCache.DeleteCalls) == 1). I tried to resemble that behaviour by creating an AutoResetEvent that gets set in the mock implementation of the method I would like to ensure it was called. Then, using Assert.True(_autoResetEvent.WaitOne()) I waited for the event to be triggered. This solution does seem to work, but if there is a better approach to this in C# I appreciate every input from the reviewers of this PR

I think your testing strategy is fine. I find the tests around caching about as readable as possible given the complexity. They look similar to the ones in other contribs.

I think my only request with them is that you add timeouts to every WaitOne() to prevent the tests from hanging forever in cases where they break because the awaited function is not called. I purposely broke some tests locally and it seems like Xunit happily runs with my CPU screaming until I manually kill the process 😂

It would be even better to add a Timeout to the Fact annotation, but apparently this doesn't work in Xunit (I tried).

[toddbaert]

Hey @bacherfl , IMO this all looks really great. I love your cache impl. I've left mostly optional/suggested changes except this one, which seems pretty small but will prevent CI/tests from hanging if people break something when making changes.

[bacherfl]

Hey @bacherfl , IMO this all looks really great. I love your cache impl. I've left mostly optional/suggested changes except this one, which seems pretty small but will prevent CI/tests from hanging if people break something when making changes.

Thanks @toddbaert for your review and suggestions - I agree with all of them, and will try to include them into this PR

[bacherfl]

alright, I have submitted all changes/suggestions, so the PR should be ready for another review :)

[toddbaert]

lgtm!