Use parameter struct for configuring QUIC streamer

[sakridge]

Problem

Methods with too many complicated parameters and duplication of parameterizing the quic server.

Summary of Changes

Add a parameter struct to pass the QUIC server parameters.

Fixes #

[alessandrod]

nice thanks

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.

[alessandrod]

@sakridge I merged this since I'm doing changes that would conflict otherwise

[sakridge]

@sakridge I merged this since I'm doing changes that would conflict otherwise

great, thanks

[t-nelson]

these change break a public interface with external consumers. we should not be changing the function signatures like this

prefer something like spawn_server_with_config that spawn_server calls after constructing the config. then we deprecate spawn_server

recommend revert and resubmit

[lijunwangs]

these change break a public interface with external consumers. we should not be changing the function signatures like this

prefer something like spawn_server_with_config that spawn_server calls after constructing the config. then we deprecate spawn_server

recommend revert and resubmit

hmm. yes, the jito-relayers were using the interfaces.

[sakridge]

these change break a public interface with external consumers. we should not be changing the function signatures like this

prefer something like spawn_server_with_config that spawn_server calls after constructing the config. then we deprecate spawn_server

recommend revert and resubmit

When did we ever bless these as consumable? Not every function we make public in a crate is intended to be consumed, and if so it's at your own risk of it being changed.

[lijunwangs]

https://crates.io/crates/solana-streamer/reverse_dependencies?page=3 -- only jito relayers are using it directly. I guess it won't be too difficult to correct their code.

[alessandrod]

When did we ever bless these as consumable? Not every function we make public in a crate is intended to be consumed, and if so it's at your own risk of it being changed.

Yeah I think I raised this a couple of times on discord, but by now I'm running with the assumption that all these crates and symbols are not really API unless they're re-exported by on chain stuff (which we should never break). Like... in this quic module we're even exporting rt which is clearly an internal util.