v2.1: Extract client code in send_transaction_service into a new structure (backport of #3423)

[mergify]

Problem

In order to be able to use new client code in the SendTransactionService (see #3444), I need to wrap network-related code with the new structure ConnectionCacheClient.

Summary of Changes

To extract network code into a new structure, I had to move some auxiliary code into separate files.
Beside of that, changes are pretty minimal and I deliberately haven't tried to optimize existing code to keep changes minimal. It just does almost exactly the same as the old one.

---

This is an automatic backport of pull request #3423 done by [Mergify](https://mergify.com).

[mergify]

If this PR represents a change to the public RPC API:

1. Make sure it includes a complementary update to rpc-client/ (example)
2. Open a follow-up PR to update the JavaScript client @solana/web3.js (example)

Thank you for keeping the RPC clients in sync with the server API @mergify[bot].

[alessandrod]

This is RPC only code, doesn't change anything in the validator and it's mostly moving existing code around.

I want to backport it because I did some changes to the quic server that give better throughput and lower resource load if the client generates a transaction stream that doesn't have high fragmentation. The FD quic server does the same, and is even stricter in that it only allows very minimal fragmentation.

This is a preparatory PR to ultimately make send-transaction-service optionally use the new quic-client-next crate to send transactions. quic-client-next doesn't create stream fragmentation. Again, RPC only, so zero risk for the validator.

[KirillLykov]

@bw-solana could you have a look?

[bw-solana]

The code itself looks fine to me.

The only hesitation I have is changing public items in published sts crate. The amount of changes for public items is surprisingly minimal, but non-zero.

Do we know who we might break with this?

[KirillLykov]

This service is quite internal thing (can be used only together with RPC), so I generally doubt anyone uses it.
@bw-solana the only public crate that depends on it is elipsis client (they depend on version < 1.19), but looking into their code I found that they don't really need to depend directly on it. So this is not a problem.

[anza-team]

😱 New commits were pushed while the automerge label was present.

[jacobcreech]

@bw-solana @alessandrod can we not just separate the crate and bump the major version? If this is making a breaking change with >2000 downloads a day, we cannot possibly alert everyone using it ahead of time.

[bw-solana]

@bw-solana @alessandrod can we not just separate the crate and bump the major version? If this is making a breaking change with >2000 downloads a day, we cannot possibly alert everyone using it ahead of time.

We've discussed this - haven't come to consensus yet. @willhickey captured things well here: #3724

[t-nelson]

i don't understand why the interfaces were changed in the same PR as breaks the types out to their own module. way too noisy even for master

[KirillLykov]

i don't understand why the interfaces were changed in the same PR as breaks the types out to their own module. way too noisy even for master

Changes in public API that I found:

1. SendTransactionService::new_with_config and new: removed reference from connection_cache: &Arc<ConnectionCache>. It is because it was cloned twice anyways.
2. pub(crate) struct SendTransactionServiceStatsReport -- added pub(crate), used to be pub
3. pub(crate) struct CurrentLeaderInfo<T> -- added pub(crate), used to be pub

What has been moved:

1. SendTransactionServiceStats to a separate module. The structure is unchanged, just moved from the send_transaction_service.rs to reduce the lenght of this file. I can do it in a separate commit to simplify the review.
2. Also moved CurrentLeaderInfo to a another module.

Would it help if I create a separate commit that would extract these structures from the original module? I can also revert for this backport these pub(crate) change.

[alessandrod]

i don't understand why the interfaces were changed in the same PR as breaks the types out to their own module. way too noisy even for master

Because nobody ever cared about APIs so far, and we don't have a CI hook that breaks CI if API is inadvertently broken. I welcome the interest in being adults with APIs going forward, but you can't just manifest it, things have to change. In the meantime, we're trying to unfuck RPC so that we stop doing ethereum level throughput. This PR is one of many, we're already trying to split, but we're also trying to get everything landed at a decent speed. Keep in mind that this is a huge chore for Kirill who's agreed to fix code that nobody wants to touch, and a source of aneurysms for me as I review all his changes.

[alessandrod]

i don't understand why the interfaces were changed in the same PR as breaks the types out to their own module. way too noisy even for master

Changes in public API that I found:

1. `SendTransactionService::new_with_config` and `new`: removed reference from `connection_cache: &Arc<ConnectionCache>`. It is because it was cloned twice anyways.

Can this be undone without breaking anything?

2. `pub(crate) struct SendTransactionServiceStatsReport` -- added pub(crate), used to be pub
3. `pub(crate) struct CurrentLeaderInfo<T>`  -- added pub(crate), used to be pub

Then I guess this can easily be reverted.

What has been moved:

1. `SendTransactionServiceStats` to a separate module. The structure is unchanged, just moved from the `send_transaction_service.rs` to reduce the lenght of this file. I can do it in a separate commit to simplify the review.

2. Also moved `CurrentLeaderInfo` to a another module.

Would it help if I create a separate commit that would extract these structures from the original module? I can also revert for this backport these pub(crate) change.

Moving seems fine, just re-export from where they used to be exported.

Let's fix the API breakage, but also let's minimize churn please. I don't want this STS fix to take another month to land. I want to move on and go back to pretending that RPC doesn't exist.

[alessandrod]

@bw-solana @alessandrod can we not just separate the crate and bump the major version? If this is making a breaking change with >2000 downloads a day, we cannot possibly alert everyone using it ahead of time.

https://crates.io/crates/solana-rpc/reverse_dependencies

there are probably 2 to 3 actual consumers of the API besides us

[t-nelson]

> i don't understand why the interfaces were changed in the same PR as breaks the types out to their own module. way too noisy even for master Because nobody ever cared about APIs so far, and we don't have a CI hook that breaks CI if API is inadvertently broken. I welcome the interest in being adults with APIs going forward, but you can't just manifest it, things have to change. In the meantime, we're trying to unfuck RPC so that we stop doing ethereum level throughput. This PR is one of many, we're already trying to split, but we're also trying to get everything landed at a decent speed. Keep in mind that this is a huge chore for Kirill who's agreed to fix code that nobody wants to touch, and a source of aneurysms for me as I review all his changes.

Oh I don’t care that they were both changed so much as that they were both changed in the same pr, making the entire set difficult to review with confidence

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[mergify]

If this PR represents a change to the public RPC API:

1. Make sure it includes a complementary update to rpc-client/ (example)
2. Open a follow-up PR to update the JavaScript client @solana/web3.js (example)

Thank you for keeping the RPC clients in sync with the server API @mergify[bot].

[KirillLykov]

This became pub here to be used in transaction_client

[KirillLykov]

@t-nelson I added a commit that moves back the Stats structure and reverts some other changes (pub(crate)). The intention is to revert this commit later in this PR

[KirillLykov]

Red CI is unrelated, see https://discord.com/channels/428295358100013066/560503042458517505/1315755154338877511

[KirillLykov]

now CI breaks after update branch because error: 2 vulnerabilities found! for some crates. Again, unrelated to these changes.

[KirillLykov]

@t-nelson please ignore CI failures, looks like 2.1 branch constantly faces some CI failures (unrelated to this PR).
For the sake of review simplicity, I returned the moved structure to the original place. I will revert this commit as soon as you confirm that these changes make sense. To prevent API changes due to structures movement, I plan to add commit that does pub use so that use for client is not affected (but structures are moved).