feat: proxy sdk

[sighphyre]

This adds implementation of Unleash that talks to the proxy endpoints on Edge. This implements the same external interface as the existing DefaultUnleash but the implementation details of a Proxy SDK are very different behind the scenes, which makes for some significant design decisions. The responses returned from the proxy endpoints do not return enough data for the existing SDK to reuse so I've split this out at the repository layer. I don't believe this is a major problem, the construction of the objects is handled by the existing UnleashBuilder, consumers that want to manually construct instances will need to know what they're doing.

• The API responses are completely different, toggles in Client response can't be handled independently because of segments, while the Proxy responses can. Because of this, I've used the single toggle responses for the Proxy SDK so that the consumer will only incur the cost of toggles they use (API and cache throughput). This means retrieving from cache is significantly lighter than using the existing DefaultUnleash
• Registration is not handled by Proxy SDKs directly, this is handled by the Proxy or Edge and so registration is a no-op in the DefaultProxyUnleash class
• The DefaultProxyUnleash class reuses the existing builder, context, caching layers, configuration, and metrics handlers. It does not reuse the existing UnleashRepository or Feature classes. This is intentional for a few reasons: behind the scenes retrieving the relevant feature toggle for the Proxy SDK requires the actual context object to make the decision on how to resolve the feature (the resolution itself is handled by Edge/Proxy). So the method signature looks like this:

    public function findFeatureByContext(string $featureName, ?Context $context = null): ?ProxyFeature;

• The above is pretty much unavoidable, since that's how the Edge/Proxy works. The returned ProxyFeature is a very stripped down version of whats contained in the existing Feature class, but more to the point, the fields mean vastly different things. While it's probably possible to force the DefaultProxyFeature and DefaultFeature classes to share an interface, I don't believe this is correct, since doing so will signal to consumers that they're interchangeable, when they very much are not.
• Because the variant returned from Edge/Proxy contains only the fields that are useful for the consumer and not things like weight or stickiness I've created a new interface and class called ResolvedVariant/DefaultResolvedVariant which is now returned from the high level public interfaces, containing only the relevant fields. The existing code now uses the existing Variant/DefaultVariant for internal calculations but no longer exposes it through the high level interfaces. This is a breaking change, albeit a small one

[gastonfournier]

I think most of my comments are details, I'm more than happy to review again after you go over them

[RikudouSage]

Overall it looks good, just leaving some comments.

[RikudouSage]

Everything looks good to me now, let me know if you're done with all the changes and I'll be happy to merge.

[sighphyre]

Everything looks good to me now, let me know if you're done with all the changes and I'll be happy to merge.

Yes! I'm all happy, shall we merge and release this?