feat(flags): remove Unleash get_variant patching code

[aliu39]

Follow-up to #3888

Fixing logic error:
After rereading https://docs.getunleash.io/reference/strategy-variants and testing w/ a local Unleash instance, I found we need to use a different variant field, feature_enabled. enabled refers to whether the variant itself is enabled, but a feature/"toggle" can be enabled with no variants. In this case, a disabled variant is returned (see no_variant_payload in tests).

---

Update:
The original PR patched 2 methods used for evaluating feature flags, is_enabled (simple toggle on/off) and get_variant (returns a dict of metadata, see https://docs.getunleash.io/reference/sdks/python#getting-a-variant).
We want to remove all get_variant code since we only support boolean flag evals atm. It seems like Unleash's main usecase for variants is reading payloads (non-bool) for A/B/multivariate testing. This could lead to a lot of extraneous flags, so until it is requested and/or we support non-bool values, let's not patch this method.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.17%. Comparing base (fa241c3) to head (7c40943).

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3914      +/-   ##
==========================================
- Coverage   80.20%   80.17%   -0.03%     
==========================================
  Files         140      140              
  Lines       15412    15403       -9     
  Branches     2593     2593              
==========================================
- Hits        12361    12350      -11     
- Misses       2206     2207       +1     
- Partials      845      846       +1     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/unleash.py	91.30% <ø> (-2.45%)	⬇️

... and 3 files with indirect coverage changes

[cmanallen]

@aliu39 How are people using get_variant in practice? Does it make sense to send a true, false value to Sentry if what the user is actually working with strings a, b, or c?

[aliu39]

@aliu39 How are people using get_variant in practice? Does it make sense to send a true, false value to Sentry if what the user is actually working with strings a, b, or c?

Discussed on a call, also looping in the FFs slack channel