Check whether fuzzer is still leaking, consider porting to C++

[cdleary]

@jbaileyhandle Very interesting, the fuzzer OOM could be also why our nightly worker blows up. I'll file an issue and look into that. Maybe something different about google3 multiprocessing vs OSS...

Originally posted by @cdleary in https://github.com/google/xls/pull/121#issuecomment-683172639

[cdleary]

The fuzzer internals have changed quite a bit, this might be better reframed as "port the remaining fuzzer infrastructure to C++" -- we'll probably get a speedup over the current Python multiprocessing approach by doing so as well, and maybe can make it a bit easier to switch between thread based workers and process workers.

Still, would be interesting to know if we crank up the fuzz sample count if we're seeing what looks like leaky behavior. Some "leakiness" can come from just having a lot of outstanding samples in flight in the multiprocess queues, but those should also be bounded size in the number of permitted outstanding entries.

[meheff]

I'm guessing this is no longer an issue as many of the parts of the fuzzer have been ported over to C++ and we don't see ooms any more.