work_type, is_http1, is_proxy_http2 and is_work_http2 seem redundant, do we need all of these functions or can we maybe have one? Seems the functions boil down what HTTP version is used so maybe one function for getting the version is enough?

They are subtly different. oha supports connecting through a proxy, and the proxy can be either HTTP1 or HTTP2. DIfferent logic is needed to setup the proxy connection in these cases. There are places in the codebase where is_proxy_http2 is used instead of the work_type for this reason.

Can we boil it down to two protocol flags, e.g. work_protocol and proxy_protocol? Feels like that might be easier to maintain in the long run instead of having multiple different functions .

Is there a reason for changing the unit type to None? Also this change seems separate from the protocol related changes, could be a separate commit with message explaining it.

Yes, it's because in the parallel_work_http* functions, the sent value is used to set the latency correction (if there is one). You'll see that work_with_qps_latency_correction now does tx.send(Some(now)). Previously these transmitters just sent () or now respectively, so an Option seemed like the right way to unify them.

                while let Ok(rx_value) = rx.recv().await {
                    let mut res = client.work_http1(&mut client_state).await;
                    if let Some(start_latency_correction) = rx_value {
                        set_start_latency_correction(&mut res, start_latency_correction);
                    }

Yeah that makes sense. Would be great to have this as a separate commit since it's not related to the protocol changes.

If we don't have this then we can't have the shared 'work' functions, which is the main goal of this CR.
For example, the new parallel_work_http1 takes a receiver of type rx: AsyncReceiver<Option<Instant>>. This is so that it can be called by both work_with_qps and work_with_qps_latency_correction, in this CR.

Yes you are right, probably the better order of changes would be to first change the existing work functions to operate on the Option type, and then in the second pahase generalize the work functions. It's more work for sure, but it enables reading through the git commit history change-by-change, and in the optimally each commit also has test coverage added/modified (if there's functional change) to validate that specific change. For open source this is especially useful since there may be many people looking at the code (and commit history) who don't have context on the changes