Make TaskExecutor a wrapper around TokioExecutor

[aaronmondal]

Instead of custom-managing a pool of futures we now spawn tasks directly. This simplifies task handling significantly and enables migration to hyper 1.x which wasn't compatible with the old TaskExecutor.

---

This change is 

[aaronmondal]

+@allada +@adam-singer +@caass +@jhpratt

Reviewable status: 0 of 4 LGTMs obtained, and pending CI: Analyze (javascript-typescript), Analyze (python), Bazel Dev / ubuntu-22.04, Cargo Dev / macos-13, Cargo Dev / ubuntu-22.04, Installation / macos-13, Installation / macos-14, Installation / ubuntu-22.04, Local / ubuntu-22.04, Publish image, Publish nativelink-worker-init, Publish nativelink-worker-lre-cc, Remote / large-ubuntu-22.04, asan / ubuntu-22.04, docker-compose-compiles-nativelink (20.04), docker-compose-compiles-nativelink (22.04), integration-tests (20.04), integration-tests (22.04), macos-13, pre-commit-checks, ubuntu-20.04 / stable, ubuntu-22.04, ubuntu-22.04 / stable, vale, windows-2022 / stable (waiting on @adam-singer, @allada, @caass, and @jhpratt)

[adam-singer]

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: 1 of 4 LGTMs obtained, and pending CI: Bazel Dev / ubuntu-22.04, Cargo Dev / macos-13, Cargo Dev / ubuntu-22.04, Installation / macos-13, Installation / macos-14, Installation / ubuntu-22.04, Publish image, Publish nativelink-worker-init, Publish nativelink-worker-lre-cc, Remote / large-ubuntu-22.04, asan / ubuntu-22.04, docker-compose-compiles-nativelink (20.04), docker-compose-compiles-nativelink (22.04), integration-tests (20.04), integration-tests (22.04), macos-13, ubuntu-20.04 / stable, ubuntu-22.04, ubuntu-22.04 / stable, windows-2022 / stable (waiting on @allada, @caass, and @jhpratt)

[allada]

Reviewed all commit messages.
Reviewable status: 2 of 4 LGTMs obtained (waiting on @caass and @jhpratt)

---

src/bin/nativelink.rs line 733 at r1 (raw file):

                        let serve_connection = if let Some(tls_acceptor) = maybe_tls_acceptor {
                            match tls_acceptor.accept(tcp_stream).await {
                                Ok(tls_stream) => Either::Left(http.serve_connection(

fyi, you can use .left_future() and .right_future() in FuturesExt.

[aaronmondal]

-@caass -@jhpratt

Reviewable status: complete! 2 of 2 LGTMs obtained

[aaronmondal]

fyi, you can use .left_future() and .right_future() in FuturesExt.

@allada I wasn't sure whether the method chaining could lead to reduced performance compared to directly using the enum. But it turns out that this is not the case and performance-wise this seems to be purely a matter of style preference: https://docs.rs/futures-util/0.3.30/src/futures_util/future/future/mod.rs.html#222-225

In terms of error messages I found it easier to debug with Either as it provides more "direct" error messages with concrete types (similar to e.g. Some) rather than raising "unsatisfied trait bound" messages.