Split up testnative

[sinkingsugar]

I added 2 new tests to test fragmentation of secio/noise with big packets and on one of the CI providers (and 32bits builds only afaik) they caused the big monolitic testnative to fail even before the new tests were even called.
I know @dryajov also had issues in the past with tests order etc.

The reality is that our tests are ok but not perfect. We barely release all the resources and close what needs to be closed. There are lingering Futures and what not.

So my question is why not just pay the price of a bit slower builds (should not be too slow if we share nimcache no?) and split the monolitic testnative in many other tests?
Why this was not done from the start btw? slow build times?

Related to #75

P.S. until this situation is handled I'm putting on hold adding
https://github.com/sinkingsugar/nim-libp2p-rs-interop

[arnetheduck]

Why this was not done from the start btw? slow build times?

because otherwise, there's no easy way to run all tests and it seemed wrong to optimize test running for hiding resource leaks.

Also, the problem will not be limited to different test modules - also individual tests that run after one another will have this issue albeit at a smaller scale.

[dryajov]

Can you describe what is failing for you now? Can you isolate the tests that's failing as well?

[sinkingsugar]

Well for now it's a "operation not on a socket" error from chronos popping.
https://ci.appveyor.com/project/nimbus/nim-libp2p/builds/31759110/job/ixrkjc2jna7rn9c8
But it's not systematic at all.
One of the issues is that we barely close any resource and we also do not wait the release of many of them.