Simplify LMDB resize

[Doy-lee]

Removing of some unused headers. Enforcing the code defined by ENABLE_AUTO_RESIZE (that macro has been defined for 10 years and isn't ever going away) and also replacing the previous LMDB resize logic with something simpler resembling more like dynamic array growth (grow by 1GiB when 90% full always vs maybe check the last 100 blocks to estimate the size of a batch of blocks being written to the DB or use this other heuristic to grow the DB).

The meat of the changes:

The resize logic before this change was quite intricate with it reading
the previous window of blocks for the average size, then, applying some
fudge-factor ontop of it to try and overshoot the expected number of
bytes required so writing the objects to the DB doesn't fail.

It's actually still possible for this to fail if you had a batch of
blocks that were larger than the remaining space in the DB because
inherently the DB was unable to resize in the middle of a batch.

This is all-nice machinery that we don't necessarily need with some
sensible resizing logic:

1. We always increase the size of the DB by 1 GiB. Before this, we'd
enumerate the size of the payload and check if we overflowed, and then,
do some logic to choose a reasonable size.

Since we now only increase in 1 GiB increments, to ensure this doesn't break
we need to ensure that any blockchain payload cannot exceed 1 GiB. The
current default syncing window is 100 blocks per payload (and increasing
it above this is quite dicey as the node actually can't support much
higher than this without encountering some internal errors) and so for
1 GiB to be reasonable it must not be possible for a 100 block payload
to exceed 1 GiB. It's reasonable to assume that we won't have a window
of 100, 10MiB blocks without hitting some block weight limit or some
fatal exploit to bloat up the blocks.

Even if this were possible however, I've added an additional change which
ensures that in practice writing to the DB will always work as follows.

2. Allow a batch to be paused mid-write to resize the DB before continuing the
batch. This was as simple as stopping the batch before resize and
restarting the batch afterwards.

This now means that the _only_ way to break a write to the DB is to insert a
_single_ object that is larger than 1 GiB. The only individual item even
remotely close to this is the SNL blob. As of current with at most
2 years worth of 10k intervals and the last 60 SNL states, that consumes
~140 MiB which has plenty of leeway to grow.

As a result, assuming these assumptions we can drop the complicated
resize logic for a simpler resizing scheme.

--

Currently letting the node resync the chain from scratch to see if there are any issues. Will update when that is done successfully.