Right now, we explicitly use the wrapped object's layout for reporting, which is technically correct from a "show me the allocation as it was requested". However, for workloads with many smaller allocations, we could be using a significantly higher amount of memory by virtue of our wrapper header.

Given that the intent is to report allocations faithfully, and as precisely as we reasonably can, we should likely switch to using the size of the wrapped allocation overall.

We changed the token registry update logic to avoid using arc-swap as it involved allocations on the read path which could lead to reentrant brokenness. However, the code we switched to is a lot lower-level and more unsafe and gnarly.

Luckily, it really just depends on normal atomics so it's likely a ripe candidate to test with loom for correctness.

(Based on an idea originally crafted by @jswrenn in his fork: https://github.com/jswrenn/tracking-allocator/blob/wild-idea/src/allocator.rs)

A major problem of the current design is that implementors must go to fairly extreme lengths to correlate deallocations with allocations, including the hoops that must be jumped through, in general, to avoid reentrant (de)allocations in the tracker implementation.

This PR does two major things:

• avoids reentrancy in AllocationTracker::allocated/AllocationTracker::deallocated by temporarily short-circuiting the logic to call it when we're already calling it
• adds the group ID as a field that comes before the requested allocation layout so it can be read in the deallocation path

Effectively, implementors can now more easily (de)allocate during tracker calls if necessary, and they can fully correlate a deallocation with the original allocation, in terms of group ID. Doing so before would have required literally tracking allocations by pointer address, which was... basically intractable.

Additionally, we've added AllocationRegistry::untracked which allows (de)allocating outside of the normal tracker codepaths as there may be a desire to allocate after tracking has been enabled, but not have it be attributed to any group.

Implements the suggestion of using a thread-local variable to prevent infinite recursion when the user's AllocationTracker, itself, allocates.

Instead of a separate variable, this PR reuses CURRENT_ALLOCATION_TOKEN. In brief, Allocator<A>::{alloc,dealloc} now set CURRENT_ALLOCATION_TOKEN to None, call AllocationTracker::{allocated,deallocated}, then, finally, restore the value of CURRENT_ALLOCATION_TOKEN.

This approach is very lightweight: the overhead is, essentially, just two additional writes to an &mut Option<AllocationGroupId>. There's no detectable performance regression.

This feature is required to call .extensions_mut on a SpanRef.

Without this change, I was getting a compile error trying to build tracking-allocator as a dependency.

This PR allows users to correlate between the group_id of allocation events and AllocationGroupToken. Specifically:

• A new AllocationGroupToken::id method turns an AllocationGroupToken into an AllocationGroupId.
• The group_id parameter of AllocationTracker::allocated is now a AllocationGroupId.

Unlike AllocationGroupToken, the AllocationGroupId type may be freely copied, compared and hashed.

In certain cases, leaving tracking enabled before main exits can lead to reentrancy of the tracking infrastructure as cleanup routines as triggered. As a concrete example, if println! is used in the allocation tracker implementation, this causes a panic at program exit:

• implicit cleanup routine for stdio runs at end of main
• this routine takes a lock and mutably borrows some internal state from a RefCell
• a deallocation happens, which drops us into allocation tracking
• as we println! in the allocation tracker, this drops us back into the print infrastructure
• the locks guarding stdout/stderr are reentrant, so we still able to take them
• the code again tries to mutably borrow some internal state, but alas, it is already borrowed
• gasp! le panic.

While printing directly in the allocation tracker implementation is not advised, this still represents a general issue where we likely shouldn't be tracking anything past actual program code, which using a drop guard should achieve: we can clear the tracker implementation right before any runtime boilerplate cleanup runs.

We recently fixed a bug where dropping the allocation group guard for an already exited group lead to trying to transition to idle when the group was already idle, which caused a panic as it is not correct behavior.

We need to write a test to back up that change and ensure we don't regress in the future.