feat: allow tracking state across requests in tokio_thread

[thomaseizinger]

Description

Due to limitations in how async blocks interact with closures, it is impossible to borrow something from outside of a closure into an async block. A custom transport implementation may want to track state for the lifetime of the thread, in addition to the rate limiter.

We make this possible by adding another state argument.

Issues

Related: #949

Reminders

• Add GH Issue ID & Linear ID (if applicable)
• Add an entry to CHANGELOG.md, following the format of existing entries
• The PR title should use Conventional Commits style (feat:, fix:, ref:, meta:, etc.)
• Useful links for external contributors: Sentry SDK development docs, Discord community

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.65%. Comparing base (a57b91c) to head (1af875c).
⚠️ Report is 31 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #950      +/-   ##
==========================================
- Coverage   73.81%   73.65%   -0.16%     
==========================================
  Files          64       64              
  Lines        7538     7515      -23     
==========================================
- Hits         5564     5535      -29     
- Misses       1974     1980       +6     

[szokeasaurusrex]

Thanks for the contribution!

I have some thoughts here:

1. As #949 makes the TransportThread public, this change to the new function is now an API-breaking change. I think we should instead keep the new function's signature unchanged, and instead, add a new function called something like new_with_state that allows for a state to be passed to the send function.
2. We should add some tests for this functionality.

[thomaseizinger]

As #949 makes the TransportThread public, this change to the new function is now an API-breaking change. I think we should instead keep the new function's signature unchanged, and instead, add a new function called something like new_with_state that allows for a state to be passed to the send function.

Well, has it been released already? If it hasn't been released yet then we could just consider this to be the new API?

I am happy to introduce a new constructor as well though, if you think it is worth having both!

[thomaseizinger]

We should add some tests for this functionality.

What would you like to have tested? The type-system enforces a lot here. Happy to add tests though if you see additional risk here.