feat: Add tokio support to anchor_client RequestBuilder

[cryptopapi997]

Picking up on #3006 since we need this for Arcium.

Adds request_threadsafe which creates a threadsafe request for usage in tokio. Fully backwards compatible.

Idk if #3053 breaks this, so would be good to get this PR merged before that one. Lmk what you think @acheroncrypto

[vercel]

@cryptopapi997 is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[acheroncrypto]

Thanks. I haven't tried it locally, but it looks great in terms of implementation other than a couple of small issues/questions I mentioned.

Fully backwards compatible.

It's mostly backwards compatible, but since RequestBuilder is public, introducing a new generic can be a breaking change for people who implement their own trait for that type (low probability).

[cryptopapi997]

Adapted according to your review:

It's mostly backwards compatible, but since RequestBuilder is public, introducing a new generic can be a breaking change for people who implement their own trait for that type (low probability).

True, although even in this case the fix is relatively easy. It's just a matter of implementing it for RequestBuilder<'a, C, Box<dyn Signer + 'a>> instead of RequestBuilder<'a, C>>.

Wdyt about having only request based on the async feature?
This would be more breaking imo, as anyone who uses request with async would have to switch to request_threadsafe which requires you to use an Arc<ThreadSafeSigner> instead of any signer like is currently the case.

Lmk what you think @acheroncrypto

[acheroncrypto]

True, although even in this case the fix is relatively easy. It's just a matter of implementing it for RequestBuilder<'a, C, Box<dyn Signer + 'a>> instead of RequestBuilder<'a, C>>.

All SemVer violations can potentially result in build errors for downstream projects, no matter how easy the fix is e.g. #3044. It's better to be safe in this case, and consider this a breaking change.

[cryptopapi997]

All SemVer violations can potentially result in build errors for downstream projects, no matter how easy the fix is e.g. #3044. It's better to be safe in this case, and consider this a breaking change.

You're right. In this case, replacing request with request_threadsafe in async seems ok.

[cryptopapi997]

All done, take a look @acheroncrypto

[acheroncrypto]

Thanks, it looks great now! However, there is an unrelated problem: solana-labs/solana-program-library#6897 is still not resolved, so we might have to make another patch release soon depending on the resolution of that issue. In that case, it would be easier to merge this PR afterwards since this is a breaking change (and I don't want to deal with multiple branches).

We shouldn't need a patch release if they just do the solution in #3044 (comment) though.

[cryptopapi997]

Since #3044 is now resolved, could you make the CI rerun so we can get this merged? @acheroncrypto

[cryptopapi997]

Also this PR needs the "breaking" tag

[acheroncrypto]

Looks great, thanks!

[Adrena-Corto]

Suffering on this, but I cannot use the latest anchor due to Solana version constraints. Not sure what are my options 🥴

[cryptopapi997]

You basically have two options in that case:

• Update Solana so you can use the latest version
• Fork the anchor version you're using and apply the changes from this PR to your fork. This shouldn't be too difficult since fortunately these changes are pretty independent of Solana itself.

Downside is you then have to maintain your own fork, so whichever of these two options is the least effort