util: add task builder API

[AlphaKeks]

Motivation

This PR implements a builder API for tokio_util::task::JoinMap as discussed in #7179.

Solution

JoinMap now has a public build_task method that returns a JoinMapBuilder. JoinMapBuilder lets you configure a name for the task and then spawn it on the JoinMap you originally got the builder from.

Because JoinMap contains a JoinSet and join_set::Builder borrows its JoinSet mutably, join_map::Builder cannot contain both a &mut JoinMap (which is required for inserting the task) and a join_set::Builder (which would borrow JoinMap::tasks). I see 2 solutions to this:

1. refactor JoinMap::insert in such a way that it is a free function instead of a method, and then make Builder contain the individual parts of JoinMap that are required
2. make Builder store all the same state that join_set::Builder (or task::Builder for that matter) stores

I chose to go with option 2, although in the future it may be better to switch to option 1, if task::Builder ever extends its API with callbacks and such.

The tokio_util::task::join_map module is currently also not public, so instead of mirroring join_map::Builder (where the join_map module is public), the Builder struct is re-exported as JoinMapBuilder. I'm not convinced this is the way to go, but making the module public would also require documenting it (which I am willing to do if desired).

[AlphaKeks]

In order for this to work, join_map::Builder needs access to tokio::task::Builder, which is gated behind tokio's tracing feature flag and --cfg tokio_unstable. So what tokio-util needs to do is enable tokio/tracing but only if --cfg tokio_unstable is also present, which I don't think Cargo is able to do?

[mox692]

Cargo cannot conditionally enable tokio/tracing based on --cfg tokio_unstable, but since tokio's tracing feature itself is always gated by --cfg tokio_unstable, I guess it doesn't really matter?

[AlphaKeks]

It matters because tokio-util already has a tracing feature (implicitly by virtue of its tracing dependency being optional). I guess we could introduce a separate feature flag that specifically enables tokio/tracing and call it something other than tracing, but I'm not sure how I feel about that.

[mox692]

Okay I see.

I guess we could introduce a separate feature flag that specifically enables tokio/tracing

Or, we might want to wait for task::Builder to stabilize ...