test: Initialize SDK in relevant tests

[alexander-alderman-webb]

Initialize the SDK with a mock transport in tests in which _execute_activation or create_activation is called, since the functions rely on tracing functions. The SDK was previously uninitialized in tests.
The initialization fixture is adapted from https://github.com/getsentry/sentry-python.

This allows us to exercise options that change the tracing behavior in tests. The tests are parametrized on the trace lifecycle in a follow up PR (#757).

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 265e126. Configure here.}

[evanh]

since the function relies on tracing functions

I don't like the idea that our main execution is reliant on the Sentry SDK. Is there a way to structure this so we capture the information but don't fail if the sentry SDK functions fail?

[alexander-alderman-webb]

Of course, you don't want your program to also fail if your observability fails.
As much as we try to not crash in the SDK, it can and has occurred, especially as we're transitioning to span streaming and dogfooding.
I'd wrap SDK function calls in try...except blocks. I think that's the way to go, particularly in something like taskbroker. If that sounds good I can do that tomorrow. Created #761 to track (or if someone else takes it, feel free to un-assign me).

[alexander-alderman-webb]

Closing as we've discussed in person in VIE that we'll keep the tests in the SDK and continue relying on the no-op client that exists when the SDK is not initialized in taskbroker tests.