tracing: replace future names with spawn locations in task spans

[hawkw]

Motivation

Currently, the per-task tracing spans generated by tokio's tracing
feature flag include the std::any::type_name of the future that was
spawned. When future combinators and/or libraries like Tower are in use,
these future names can get quite long. Furthermore, when formatting
the tracing spans with their parent spans as context, any other task
spans in the span context where the future was spawned from can also
include extremely long future names.

In some cases, this can result in extremely high memory use just to
store the future names. For example, in Linkerd, when we enable
tokio=trace to enable the task spans, there's a spawned task whose
future name is 232990 characters long. A proxy with only 14 spawned
tasks generates a task list that's over 690 KB. Enabling task spans
under load results in the process getting OOM killed very quickly.

Solution

This branch removes future type names from the spans generated by
spawn. As a replacement, to allow identifying which spawn call a
span corresponds to, the task span now contains the source code location
where spawn was called, when the compiler supports the
#[track_caller] attribute. Since track_caller was stabilized in Rust
1.46.0, and our minimum supported Rust version is 1.45.0, we can't
assume that #[track_caller] is always available. Instead, we have a
RUSTFLAGS cfg, tokio_track_caller, that guards whether or not we use
it. I've also added a build.rs that detects the compiler minor
version, and sets the cfg flag automatically if the current compiler
version is >= 1.46. This means users shouldn't have to enable
tokio_track_caller manually.

Here's the trace output from the chat example, before this change:

...and after:

Closes #3073

[hawkw]

Note that this enables track_caller on spawn even when it's not used by the "tracing" feature flag. I think this is actually a good thing, since it means the panic when spawn is called outside the runtime will have the callsite's location, which may make debugging a little easier for users?

However, if folks prefer, I can change this to only enable track_caller when the cfg is set and the "tracing" feature flag is enabled.

[hawkw]

spawn.location feels a little wordy but I couldn't think of something more descriptive off the top of my head. If folks have better ideas, let me know!

[hawkw]

also, we could alternatively record the filename, line number, and column as separate fields on the task span, like

Suggested change

	spawn.location = %format_args!("{}:{}:{}", location.file(), location.line(), location.column()),
	spawn.file = %location.file(),
	spawn.line = location.line(),
	spawn.column = location.column(),

and rely on the tracing subscriber to format them nicely...but, this results in more verbose, harder to read output when the tracing subscriber that's in use isn't doing anything fancy, so I thought this was nicer.

[taiki-e]

Probably MSRV will be increased in 1.0, so dependency on autocfg should be temporary.

However, futures-core may depend on autocfg in the future. (see rust-lang/futures-rs#2207 (comment) and rust-lang/futures-rs#1875 (comment))