Add on_spawn configuration for Builder

[malaire]

Is your feature request related to a problem? Please describe.

For monitoring and tracking purposes I want to run some custom code when any spawned task is created/polled/dropped.

Describe the solution you'd like

I propose a configuration method on_spawn for Builder which would take a wrapper function to be applied to all spawned tasks.

For example following two examples would be equivalent:

(First example in playground, with example Wrapper)

fn main() {
    tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            tokio::spawn(Wrapper::new(async {
                println!("Hello world")
            })).await.unwrap();
        });
}

fn main() {
    tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .on_spawn(Wrapper::new)
        .build()
        .unwrap()
        .block_on(async {
            tokio::spawn(async {
                println!("Hello world")
            }).await.unwrap();
        });
}

Describe alternatives you've considered

Alternative solution would be to apply this wrapper in all places where task is spawned. While this is possible for my own code, and also for crates like Hyper which offer configuration option like with_executor, this is not possible when using crates which do not offer such configuration option.

Doing this configuration for tokio runtime would be much better option.

[MikailBag]

As a downside, such an on_spawn callback can't be generic (unless the whole tokio Runtime is generic), so one additional level of indirection is added to each poll.

[malaire]

Also I'd like similar on_spawn_blocking which would apply to spawn_blocking. Both wrappers would run "in context" of parent task to have access to any task-locals of parent task.

[malaire]

@MikailBag In my use cases I'm adding some code to each poll so that indirection is required.

If there are other use cases which would only run some code on each spawn, but not on each poll, then non-wrapping callback would be better. Perhaps that could be called on_task_start, like on_thread_start?