Investigate flaky `no_runtime_allocations` test on macOS.

[tobz]

Context

We've seen the no_runtime_allocations test (in the process-memory crate) flake a few times under macOS specifically, due to allocating memory when it shouldn't be.

        FAIL [   0.257s] process-memory::no_runtime_allocations no_runtime_allocations
--- STDOUT:              process-memory::no_runtime_allocations no_runtime_allocations ---
running 1 test
test no_runtime_allocations ... FAILED
failures:
failures:
    no_runtime_allocations
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.13s
--- STDERR:              process-memory::no_runtime_allocations no_runtime_allocations ---
dhat: Total:     788 bytes in 2 blocks
dhat: At t-gmax: 788 bytes in 2 blocks
dhat: At t-end:  788 bytes in 2 blocks
dhat: The data has been saved to dhat-heap.json, and is viewable with dhat/dh_view.html
thread 'no_runtime_allocations' panicked at lib/process-memory/tests/no_runtime_allocations.rs:26:5:
dhat: assertion failed: `(left == right)`
  left: `1`,
 right: `0`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

We should figure out why that's happening.

[tobz]

Random thought I had the other day: maybe the thread stack ends up having to grow, and that's the allocation... because otherwise, I don't see how the code under test could itself be allocating like 1% of the time: it should be all or nothing.

The thread stack needing to sometimes grow a little bit based on how instructions are processed or timing-related artifacts? Feels more plausible, even if still a little questionable.

[tobz]

For now, we've decided to punt on this by marking the test to be ignored on macOS (#801).

[kris-gaudel]

Hi is this issue still relevant? I'm interested in contributing!