feat: Add features module and flagpole support

[markstory]

This is a rough pass on adding flagpole support to sentry-options. I've intentionally tried to limit the surface area that is exposed and there is only a has() and context object currently exposed.

This has largely been generated with LLM assistance during the ai-code sprint. There are still a few gaps in test coverage in the python library that I would like to shore up.

[hubertdeng123]

Curious to hear the choice to serialize the features from json to strings. Is that how it is done in sentry today? It seems nicer to have the features directly as json by using sentry's flagpole jsonschema and combine it into the namespace-schema here?

https://github.com/getsentry/sentry-options/blob/main/sentry-options-validation/src/namespace-schema.json

[markstory]

Curious to hear the choice to serialize the features from json to strings. Is that how it is done in sentry today? It seems nicer to have the features directly as json by using sentry's flagpole jsonschema and combine it into the namespace-schema here?

Yes, currently we store feature flags as strings in postgres (the options store). When the option for a feature flag is checked it is first parsed into a dict, and the dict is then converted into objects that can perform the flag logic.

I didn't know how deeply you wanted to integrate feature flags into this library. We could have a new option 'type' for feature flags that can validate against the flagpole schema. Would NamespaceOptions.get() return the FeatureData structure in that case? I assume that would also imply that we would have python objects for FeatureData as one could read a feature flag with the python interface. I was hoping to avoid having to build python structures for the FeatureData components because they should be implementation details for users of this library.

I'll explore the path of expanding the jsonschema and storing features as structured data. This approach was cheap to build, and I have no problems with tossing it.

[hubertdeng123]

Yes, currently we store feature flags as strings in postgres (the options store). When the option for a feature flag is checked it is first parsed into a dict, and the dict is then converted into objects that can perform the flag logic.

Ah right, bc we store it in the db it needs to be serialized

I didn't know how deeply you wanted to integrate feature flags into this library. We could have a new option 'type' for feature flags that can validate against the flagpole schema. Would NamespaceOptions.get() return the FeatureData structure in that case? I assume that would also imply that we would have python objects for FeatureData as one could read a feature flag with the python interface. I was hoping to avoid having to build python structures for the FeatureData components because they should be implementation details for users of this library.

I'll explore the path of expanding the jsonschema and storing features as structured data. This approach was cheap to build, and I have no problems with tossing it.

I think this is ideally what we would want, but I am ok with getting this in as strings first given that we can tighten up that experience later given that you've been so kind as to help us out here. That way deserialization only happens at the json later and not again for str -> dict.