Improving testing speed

[johnsonjh]

While the tests complete in here in less than a minute, @cjdelisle advised they are taking close to 90s for him - on Travis, they can sometimes take 10 minutes or more, depending on the load.

Here's the runtime breakdown:

The Neutrino test is 16s because it reliant on wall-clock time to do it's ban/unban testing, and is the low-hanging fruit. This test could be rewritten based on a range, or moved completely out into ALL_TESTS=1 (Neutrino has some slow, extra tests there already, including the tests that would require getting the full test harness working again.)

Anyway, for my 50s test runtime, the top 10 here are 45s of it.

[johnsonjh]

Also, the chain database and wallet db tests can likely be "optimized" by disabling fsync.

[johnsonjh]

These results are based on my fork, which has some PR's applied that aren't yet in develop, so my addrmanager/connmanager test is likely faster here and will get a bump once I rebase #212

[johnsonjh]

@cjdelisle Would you be against adding a SLOW_TESTS variable and moving the Neutrino BanMan and SeedWords tests to only be active when it's defined, line LDB_TEST?

That should take 20s off right away.

[johnsonjh]

I've fully implemented this - see #229 (comment) - it works very well without much loss of coverage. The link has all the details.

Also, I've found it's not that difficult to provide fake time data during tests so I'll soon be fixing the Neutrino BanMan test. Instead of taking 16s (or even 5s) it should be able to complete in 0.1-0.2s and won't ever throw any false positives in a CI/CD pipeline again.