Limiting recursion thoughts

I invested some time looking through Arbitrary/libfuzzer-sys to determine the best way to limit recursion (in my case). I'm going to list what I looked at:

1. https://docs.rs/libfuzzer-sys/0.4.7/src/libfuzzer_sys/lib.rs.html#262-270, how size_hint is used to bail out in case of "not enough data".
2. https://github.com/rust-fuzz/arbitrary/issues/78#issuecomment-804414060, custom Arbitrary impl with depth, switch to non-recursive generation as the limit is surpassed.
3. https://github.com/rust-fuzz/arbitrary/issues/217, coming breaking changes.
4. https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-tools%20impl%3C%27a%3E%20Arbitrary&type=code, wasm smith.

Questions I'm trying to answer:

1. Isn't using size_hint faster than limiting with a custom arbitrary implementation? If you implement size_hint, you can set the size hint to something like u64::MAX, which will be interpreted by libfuzzer-sys as not generating this input. The check for supplied bytes being less than the hint returns -1. While this may not be ideal for varying recursion depths since it's currently hardcoded, there are workarounds.
   My thought is that calculating the hint is much faster than limiting while generating the data structure, especially if you know your boundaries and just want to go a bit higher.
2. Has it been empirically found that continuously generating the non-recursive data structure improves coverage? (ref to point 2 in the previous list)

Start with the linked libfuzzer-sys source around size_hint, then read arbitrary issues 78 and 217 and inspect the wasm smith Arbitrary implementations. Compare size_hint-based rejection with depth-aware non-recursive generation, including the effect on coverage. Done means reaching an empirically supported recommendation for limiting recursion.