rt: Refactor Runtime::block_on to take &self

[LucioFranco]

This PR is the first in a series of PRs to solve #2720. This change introduces a few things.

1. Handle has been removed from the public API (only used internally until we refactor it out, likely in an upcoming PR)
2. Change Runtime::block_on to take &self. This change for the threaded runtime is quite trivial, but for basic/shell runtimes we use a Mutex<Option<Runtime>> to allow the first call to block_on to do all the parking will subsequent ones (while the first one is not done yet) will just use the context from that first block_on.

Most of this PR is removing methods from Handle, refactoring the fact that block_on is now immutable and making CachedThreadParker and friends available without any feature flags (I think this is correct there are no deps for it beyond std ones).

Future work:

• Refactor basic_scheduler/shell to embed the block_on implementation within their own structs rather than within Runtime::block_on. This means making those block_on's take &self not &mut self. Improve stealing the root parker in situations where it gets reset back into the mutex and another thread needs to now drive it.
• Review runtime shutdown process.
• Refactor runtime::Builder to remove threaded_scheduler/basic_scheduler and refactor core_threads to do the behavior described in rt: Runtime refinements #2720.
• Refactor #[tokio::main] as described in chore: prepare to release 0.2.22 #2672.

[carllerche]

Thanks for taking this on 👍 Looks good overall. I left comments inline. I'll let @hawkw +1 the PR once the changes are done.

[hawkw]

lgtm overall --- a couple questions/nits.

[hawkw]

Hmm...unlike the prior version, this now has a borrow in it, so it's not 'static. You'd have to write

let rt = ...;
some_other_future_executor::spawn(async move {
    rt.wrap(some_future).await
});

rather than

let rt = ...;
some_other_future_executor::spawn(rt.wrap(some_future));

which seems like a minor ergonomic speed bump in what i imagine is more or less the most common use case for this?

Maybe we should just clone it...what do you think?

[LucioFranco]

So Runtime doesn't implement clone anymore. But you can achieve the same thing if you async move { rt.wrap(fut) } and if you warp the Runtime with an Arc you can clone before moving.

[LucioFranco]

We can revisit this in the near future.

[hawkw]

yup,

So Runtime doesn't implement clone anymore. But you can achieve the same thing if you async move { rt.wrap(fut) } and if you warp the Runtime with an Arc you can clone before moving.

yup, i missed Carl's review feedback while looking at this. seems good to me, now that the arc is factored out. 👍

[jonhoo]

I unfortunately do not have the spare cycles these days to review this, even though I wish I did :)

[LucioFranco]

@jonhoo its all good :)

[hawkw]

lgtm!