ref(flags): register LD hook in setup instead of init, and don't check for initialization

[aliu39]

Refactors setup code and removes an error case from the LaunchDarkly integration

register LD hook in setup instead of init

IMO we should only hook into LD once, when this integration is setup by sentry_sdk.init. It's rare, but this class could be instantiated more than once, from user error, tests, etc. It's reasonable to expect Sentry init is only called once in prod.

don't check for initialization

We shouldn't fail if LDClient hasn't initialized yet. Initialization is the async process of connecting to the LD server, and may take a moment. With the setup code from our docs, we configure LD right before calling Sentry init, and don't wait for initialization to complete. This could lead to a lot of errors / failure to start your app if you have a slow internet connection. It's ultimately the user's responsibility to ensure LD is initialized before evaluating flags. Even if the client's never initialized, flags will default to False, so nothing's breaking on our end.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.88%. Comparing base (60fb6fc) to head (56e6eac).
Report is 1 commits behind head on master.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3890      +/-   ##
==========================================
- Coverage   79.89%   79.88%   -0.01%     
==========================================
  Files         139      139              
  Lines       15429    15429              
  Branches     2624     2623       -1     
==========================================
- Hits        12327    12326       -1     
- Misses       2228     2229       +1     
  Partials      874      874              

Files with missing lines	Coverage Δ
sentry_sdk/integrations/launchdarkly.py	79.48% <100.00%> (ø)

... and 4 files with indirect coverage changes

[antonpirker]

looks good.

[cmanallen]

@aliu39 This needs to be reverted. This is not the correct way to manage this behavior. Regardless, where is the documentation for this change? A notion doc or anything to describe why this is important?

[cmanallen]

Reverted here: #3900. There are too many holes in this. How would a user track multiple clients? Multiple integrations? Does that work? There are no tests for it. Let's discuss on Monday.