feat: Add environment document endpoint

[rolodato]

Adds a GET /environment-document endpoint for use by server-side SDKs in local evaluation mode.

Using the Edge Proxy this way introduces more polling (SDKs polling Edge Proxy, and Edge Proxy polling API), but at least it's polling that customers are not charged for. This lets customers scale their applications independently from their Edge Proxies.

This implementation could be more efficient, since we're iterating through all environment key pairs to find the matching server-side key. In any case, the number of environment key pairs served by a single Edge Proxy tends to be small.

[matthewelwell]

I guess some alternatives to this loop would be:

1. Create an entry in the cache for each key, including the server keys (this would obviously increase memory usage)
2. Create some other map in the cache to point from a server key to a client key

Of these 2, probably the 2nd option is the better option, but it does require a non-trivial amount of effort. I think, based on that, I'm happy with the for loop as a concept for now, but I think we should abstract it to the environment service layer and create some method like get_client_key_from_server_key(server_key: str). I guess then, we might as well just extend the get_environment method to check if the key starts with "ser.".

[rolodato]

I kept the same caching behaviour and moved this to get_environment in the service layer.

I'm not a fan of checking for server/client keys by looking at the ser. prefix, so I made get_environment require explicitly named client_side_key or server_side_key arguments.

[matthewelwell]

I'm not a fan of checking for server/client keys by looking at the ser. prefix, so I made get_environment require explicitly named client_side_key or server_side_key arguments.

While I tend to agree that it's not the neatest way of differentiation, I don't really see any actual issues with it. The issue with the approach that you've taken is that we might end up in a scenario where an application, pointing to the edge proxy, has a local evaluation and remote evaluation client running. They might though, share the same key from some environment variable. The remote evaluation client will thus fail, because it's expecting the key to be a client-side key.

Maybe this is unnecessary complication, but in opening up one endpoint to the server key, we may need to consider opening them all up.

[matthewelwell]

I just re-read the above, and it took me a while to understand again what my point was, so here's an example application to demonstrate the issue that I'm talking about.

from flagsmith import Flagsmith, Flags


FLAGSMITH_KEY = os.environ["FLAGSMITH_KEY"]

class FeatureFlagWrapper:
    def __init__(self) -> None:
        self.remote_evaluation_client = Flagsmith(environment_key=FLAGSMITH_KEY)
        self.local_evaluation_client = Flagsmith(
            environment_key=FLAGSMITH_KEY,
            enable_local_evaluation=True,
            environment_refresh_interval_seconds=300,
        )

    def get_flag_state(flag_key: str, from_local: bool = True) -> bool:
        if from_local:
            return self.local_evaluation_client.get_environment_flags().is_feature_enabled(flag_key)
        else:
            return self.remote_evaluation_client.get_environment_flags().is_feature_enabled(flag_key)

Obviously this is an over simplification, but I suspect that this is often a valid use case, where people care about certain flags being updated sooner than others, so they set a longer refresh interval on their local evaluation client, and then use a remove evaluation client for anything more sensitive. Obviously this is further complicated by the fact that we're talking about the edge proxy here, which has it's own refresh interval, but I still think this is a valid concern.