rt: unify entering a runtime with Handle::enter

[carllerche]

This is a first step towards unifying the concepts of "entering a runtime" and setting Handle::current.

Previously, these two operations were performed separately at each call site (runtime block_on, ...). This is error-prone and also requires multiple accesses to the thread-local variable. Additionally, "entering the runtime" conflated the concept of entering a blocking region. For example, calling mpsc::Receiver::recv_blocking performed the "enter the runtime" step. This was done to prevent blocking a runtime, as the operation will panic when called from an existing runtime.

To untangle these concepts, the patch splits each logical operation into a separate function. In total, there are three "enter" operations:

• set_current_handle
• enter_runtime
• enter_blocking_region

There are some behavior changes with each function, but they should not translate to public behavior changes. The most significant is enter_blocking_region does not change the value of the thread-local variable, which means the function can be re-entered. Since enter_blocking_region is an internal-only function and we do not re-enter, this has no public-facing impact.

Because enter_runtime takes a &Handle to combine the set_current_handle operation with entering a runtime, the patch exposes an annoyance with the current scheduler::Handle struct layout. A new instance of scheduler::Handle must be constructed at each call to enter_runtime. We can explore cleaning this up later.

This patch does not combine the "entered runtime" thread-local variable with the "context" thread-local variable. To keep the patch smaller, this has been punted to a follow-up change.

[carllerche]

I think the failure is due to a recent rust release. I will have to investigate later.

[carllerche]

CI fix: #5164