[Darksonn]

add_permits_locked emits a tracing event once a waiter has been
assigned all of its permits, but before removing it from the wait
queue. If the tracing subscriber panics during this event, the waiter
stays in the queue with zero permits remaining. Polling the Acquire
future again then completes it and clears queued, so dropping it
frees the waiter without unlinking it, and the next release
dereferences the freed waiter.

Similarly, poll_acquire emits tracing events after taking permits from
the semaphore, but before the Acquire future records that it holds
them, so a subscriber panic there leaks the permits. This affects both
the uncontended path, where all permits are taken at once, and the
contended path, where the available permits are taken before the waiter
is queued.

This PR contains one commit per issue:

• Remove the waiter from the wait queue before emitting the tracing
  event.
• On the uncontended path, record the permits in the waiter's state and
  set queued before emitting the tracing events, and only clear
  queued in Acquire::poll after the last tracing event. With this,
  queued consistently means that Acquire::drop must clean up after
  the waiter, and num_permits - state is always the number of permits
  it holds. (This is also the state that sync: preserve FIFO lock order when coop budget is exhausted #8371 needs when the coop
  budget runs out after the permits were taken.)
• On the contended path, assign the permits to the waiter before
  emitting the tracing event.

All of these require tokio_unstable and the tracing feature. The
regression tests use a subscriber that panics on the first event with a
given target; without the first fix, Miri reports the use-after-free.

Not covered here: a panic in the tracing calls that run after
Acquire::poll has returned (span exits and the poll_op event in
InstrumentedAsyncOp) can still leak permits, and a panic in
add_permits_locked after a waiter was removed from the queue still
loses its wakeup and the remaining permits. Neither is a memory safety
issue, and handling them would require restructuring how these futures
are instrumented.

Fixes: #8541

[Darksonn]

I'm really not sure about this one ... feel free to give suggestions or even come up with alternate fixes.

[ADD-SP]

The fix and test looks good to me. Actually, I think this is a minimal workable fix while it is not the clean fix.

BTW, it looks like our Miri tests don't cover the --cfg tokio_unstable, we can add it after merge. I ran the tests locally using Miri with tokio_unstable and it passed.