Do not always check if __main__ in result when pickling

[fjetter]

This logic evolved over time but the doc string already suggests that we're performing type checks first before we do the "is main in result" check. Some refactoring along the way changed this. Particularly for large results this can be a big difference such that the thing in result check can be more expensive than the actual serialization. This can be most strongly observed when pickling bytes directly (not sure if we're actually doing that) or more generally for everything that we're blocklisting in _always_use_pickle_for (I think we should expand this, e.g. to include arrow tables for p2p)

I ended up rewriting the logic to something that is easier to understand imo. This includes a minor functional change. Previously, it would have been possible for an object to be classified as eligible for cloudpickle by the main in result or pickle_by_value guard even though it is blocklisted by the always_use_pickle_for but only if the object was very small. This is a bit off an odd logic. In fact, it cannot even occur since always_use_pickle_for concerns instances while the pickle_by_value and main in result check concerns functions and classes. Still, imo this made the logic less readable. The new logic is subjectively easier to read and short circuits much more quickly in the happy path or always_use_pickle_for==True

[github-actions]

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

    27 files  ± 0      27 suites  ±0   9h 46m 28s ⏱️ + 2m 13s
 3 951 tests ± 0   3 839 ✅ + 1    109 💤 ±0  3 ❌  - 1 
49 696 runs  +18  47 404 ✅ +25  2 289 💤  - 6  3 ❌  - 1 

For more details on these failures, see this check.

Results for commit c5f1379. ± Comparison against base commit 7562f9c.

[hendrikmakait]

Thanks, @fjetter, changes look good to me.