HBONE connections benches

[Stevenjin8]

Benchmarks how long it takes to establish a new HBONE connection.
Do this by creating n workloads giving us O(n^2) ways to create new HBONE connections. The actual limiting factor here is not the number of workload source/destination pairs, but the number of possible open file descriptions.
This happens to me when I change the duration of the test from 5 to 10 seconds.

I confirmed this is creating new HBONE connections by running tcpdump on lo and seeing the number of TLS handshakes was more or less the same as the number of test iterations.

resolves #623

[istio-testing]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[Stevenjin8]

/test all

[Stevenjin8]

/test all

[Stevenjin8]

/retest

[Stevenjin8]

/test all

[Stevenjin8]

/test all

[Stevenjin8]

I have no idea how to fix the CI error

error: non-binding `let` on a future
   --> benches/throughput.rs:465:9
    |
465 | /         let _ = tokio::spawn(async move {
466 | |             let _ = tokio::join!(app.wait_termination(), echo.run());
467 | |         });
    | |___________^
    |
    = help: consider awaiting the future or dropping explicitly with `std::mem::drop`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#le

The other benches do the by doing let t = tokio::spawn(...) and then returning t. However, t gets eventually bound to _ so it never gets awaited

[MorrisLaw]

This section is repeated often.

e.g.

 let mut s =
    e.ta.socks5_connect(helpers::with_ip(
        e.echo_addr,
        TEST_WORKLOAD_TCP.parse().unwrap(),
    ))
    .await;

Wdyt about abstracting that logic into a helper function, maybe something called newTCPStream or similar. Have it maybe take in the TEST_WORKLOAD_<SOURCE/HBONE/TCP> string value as an argument. Would help to maintain that DRY principle while also making it convenient for the next person to extend this test with more benches?

[Stevenjin8]

I'll think about this. The whole echo server setup is clever but also confusing. You can access the echo server through any ip address on lo, but if you want to use ztunnel/socks5, the address you pick to access the echo server needs to be a registered workload.

Point is, I feel like the way its abstracted right now is already confusing, so I didn't want to abstract it any further. I do think there is probably a better way to do this. My first idea it to make TEST_WORKLOAD_* actual IP address instead of a string that can be parsed into an ip address. Thoughts?

[MorrisLaw]

The abstraction I refer to is to really help reduce the repetitive and confusing code in the tests. Using a helper function should actually make it more understandable.

[MorrisLaw]

let t won't work for your test? Is that why you did let _?

[Stevenjin8]

let t won't work for your test? Is that why you did let _?

let t doesn't work because it ends up being an unused variable. But the warning comes from the fact that I never await the result of the spawn, which is the same for the other benches.

[jaellio]

Note this is only n*(n-1)/2 combos. If we wanted more new HBONE connections from the same number of IPs this could be optimized.

[keithmattix]

Adding a .await here should fix the CI

[keithmattix]

Or an explicit drop

[Stevenjin8]

TODO: Drop works, but hoping that someone has a better solution than just orphaning the tasks.