subscriber: update sharded-slab to v0.0.8 to fix a memory leak

Version 0.0.7 of `sharded-slab` contains a bug where, when the `remove`
method is called with the index of a slot that is not being accessed
concurrently, the slot is emptied but **not** placed on the free list.
This issue meant that, under `tracing-subscriber`'s usage pattern, where
slab entries are almost always uncontended when reused, allocated slab
pages are almost never reused, resulting in unbounded slab growth over
time (i.e. a memory leak).

This commit updates `tracing-subscriber`'s `sharded-slab` dependency to
v0.0.8, which includes commit hawkw/sharded-slab@dfdd7ae. That commit
fixes this bug.

I've empirically verified that, after running `linkerd2-proxy` under
load with a global `trace` filter that enables a *lot* of spans, heap
usage remains stable, and the characteristic stair-step heap growth
pattern of doubling slab allocations doesn't occur. This indicates that
freed slots are actually being reused, and (once fully warmed up), the
slab will only grow when =the number of active spans in the system
increases.

Signed-off-by: Eliza Weisman <[email protected]>

tracing-subscriber/Cargo.toml

@@ -53,7 +53,7 @@ tracing-serde = { version = "0.1.0", optional = true }
 parking_lot = { version = ">= 0.7, < 0.10", optional = true }
 
 # registry
-sharded-slab = { version = "0.0.7", optional = true }
+sharded-slab = { version = "0.0.8", optional = true }
 
 [dev-dependencies]
 tracing = "0.1"