Improve unittests

[tequdev]

High Level Overview of Change

See XRPLF/rippled#4634

Context of Change

Before

Longest suite times:
  210.3s ripple.tx.NFToken
  125.0s ripple.tx.NFTokenBurn
  104.1s ripple.app.SetHook
   77.5s ripple.tx.Offer
   67.3s ripple.app.SetHookTSH
   48.7s ripple.app.TheoreticalQuality
   48.5s ripple.tx.NFTokenDir
   47.2s ripple.app.ValidatorSite
   42.1s ripple.app.XahauGenesis
   39.9s ripple.app.PayChan
212.3s, 232 suites, 2866 cases, 724223 tests total, 0 failures

After

Longest suite times:
   52.3s ripple.tx.NFToken4
   51.8s ripple.tx.NFToken1
   51.8s ripple.tx.NFToken2
   51.1s ripple.tx.NFToken3
   50.8s ripple.app.TheoreticalQuality
   50.5s ripple.tx.NFToken0
   47.4s ripple.app.XahauGenesis
   46.5s ripple.tx.NFTokenDir
   40.0s ripple.app.ShardArchiveHandler
   38.3s ripple.tx.NFTokenBurn2
71.1s, 250 suites, 2888 cases, 724161 tests total, 0 failures

(28 core)

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)