Optimize RocksDB WAL file

[fab-10]

PR description

Currently Besu uses the default RocksDB WAL options, with the result that usually the WAL files could occupy ~15GB of disk space, due to the fact that different column families are flushed at very different intervals, this has also the bad effect of slow restarts, when Besu has to parse an reapply all these WAL files.

Capping the WAL files total size to 1GB and reusing old files when possible, has the advantage of a faster restart, and a more linear disk usage, instead of the classic saw tooth shape that we see today.

Fixed Issue(s)

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I thought about the changelog and included a changelog update if required.
• If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[ahamlat]

LGTM, I'm wondering why would WAL occupy 15 GiB, each memtable has 64 MiB size, knowing that there are two memtables per column family and 7 column families in worst case, this gives as :
64 * 2 * 7 = 896 MiB

We can find in RocksDB documentation this example :

For example, with 15 column families, each with
   *  write_buffer_size = 128 MB
   *  max_write_buffer_number = 6
   *  max_total_wal_size will be calculated to be [15 * 128MB * 6] * 4 = 45GB

I couldn't find in the documentation what is 4 in this formula, but even by applying this formula, the result will be 3584 MiB (896 * 4)

[fab-10]

From https://github.com/facebook/rocksdb/wiki/Write-Ahead-Log-%28WAL%29

DBOptions::max_total_wal_size
In order to limit the size of WALs, RocksDB uses DBOptions::max_total_wal_size as the trigger of column family flush. Once WALs exceed this size, RocksDB will start forcing the flush of column families to allow deletion of some oldest WALs. This config can be useful when column families are updated at non-uniform frequencies. If there's no size limit, users may need to keep really old WALs when the infrequently-updated column families hasn't flushed for a while.

So the ~15GB the WALs occupy, consist mostly of unneeded data, since the data has already been written for all the column families but one that is infrequently flushed, and that single column family is enough to keep these files around, setting the limit forces a regular flush of that column family.