API design suggestion

[Jimmy-Z]

s2n-quic's API uses the method chaining paradigm, which is - dare I say - often implemented poorly, and I believe s2n-quic is one of them.

The current design works fine if the caller wants to just hardcode (almost) everything, like in the examples, but what if the caller want something configured at runtime?

1. let's see the example of .with_gso_disabled(), the caller would need to write something like:

let mut builder = Builder::new();
if !args.gso {
    builder = builder.with_gso_disabled();
}
let server = builder.build();

which does not really conform to the method chaining paradigm.
and it doesn't work for some methods since the method might return a different type, which I gave an example here: https://users.rust-lang.org/t/a-question-about-method-chaining-with-different-return-types/104196

I think a better design would be a .with_gso() method that takes a bool value (or a enum with auto|force_on|force_off or something like that), like this:

let server = Server::builder()
    .with_gso(args.gso)
    // ...
    .start();

2. some methods, like the .with_congestion_controller() looks like it works like that, but since Cubic and Bbr are actually different types, we can't really do this:

builder.with_congestion_controller(if args.bbr {Bbr::default()} else {Cubic::default()}) ...

Sorry for the critical tone and strong wording.

And it's also entirely possible that it's just that my rust-fu is too weak, and this problem is entirely solvable from the caller side, if then, my sincere apologies and please show me how.

[camshaft]

Thanks for the suggestions! I've implemented the first item in #2091.

For the second item, it's a bit trickier. But I think if you're ok with doing runtime dispatch, then we can provide a helper enum that forwards the congestion controller methods on to the correct impls. I've opened #2092 to track that.

[toidiu]

The work to ergonomically switch CC is being tracked in #2092