Hi all 👋

We already released the addon-framework where we want to provide out-of the box integrations with third party tools. It would be super helpful if someone familiar with New Relic could assist on building the New Relic integration. The idea is to inform New Relic about changes via [New Relic Custom events](https://docs.newrelic.com/docs/telemetry-data-platform/ingest-apis/introduct

And, ideally, a configurable list of annotations denoting generated source or AST structures.

See #105 for the kind of issue this seeks to avoid, and the limitations of this fix.

As we are constantly upgrading Flagr server, the client SDKs may experience unexpected changes from the server side. The integration tests should better include these SDKs instead of just simple CURL tests.

Specifically, we want to cover

• https://github.com/checkr/jsflagr
• https://github.com/checkr/rbflagr
• https://github.com/checkr/pyflagr
• https://github.com/checkr/goflagr

Hi,

It is quite stupid to have one type for many events.
Suggestion:
On feature_segment update sends : FLAG_SEGMENT_UPDATED
On feature_identity update sends : FLAG_IDENTITY_UPDATED
on feature update sends : FLAG_FEATURE_UPDATED

Requirements

Add an environment parameter in the config.
This environment field should be added to all users in the param so we can add rules based on the environment and have the same config file for all your environment.

Right now, when you archive a key, you can only see it if you manually search for it.

This can cause some key name conflict issues, or issues when trying to create a folder with the same name as an archived (bu not yet deleted key).

It would be ideal for there to be a way to see all archived keys at once, without the need to search for them in the search bar.

Documentation is not up to date

For example, supported datastores misses PGSQL
https://maif.github.io/izanami/manual/architecture/index.html

Please documentation freshness problems in this issue

I am currently writing some custom strategies that are simply gradual rollout strategies similar to the built in one for user IDs but these are keyed off of different data specific to my use case. I want to make sure that my gradual rollout strategy uses the same normalization, rounding, etc. that the built in gradual rollout strategies use.

However, that logic is defined inside of `internal/st