Introduce new V4 format addrman #23354

#23306 effectively changed the on-disk format in an incompatible way: old deserializers cannot deal with multiple entries for the same IP.

Introduce a V4_MULTIPORT format, and increment the compatibility base, so that old versions correctly recognize it as an incompatible future version, rather than corruption.

Concept ACK

ACK d891ae768185b464cae476c16c74c365372d4a3c

utACK d891ae768185b464cae476c16c74c365372d4a3c

I tested the "correct" error message (failing to load because of version). Testing the "wrong" error message (corruption) might be harder, as it requires -checkaddrman (or the implicit check), both of which are only in master, thus require re-compilation. So I think a regression-test with previous releases is not possible, at least not in the functional test framework.

So I tested the new format manually:

$ ./src/bitcoin-cli -regtest -datadir=/tmp/test_23354/ addpeeraddress "250.1.1.2" 12345 
{
  "success": true
}
$ ./src/bitcoin-cli -regtest -datadir=/tmp/test_23354/ addpeeraddress "250.1.1.2" 12367 
{
  "success": true
}

Start with previous versions prints the correct error now:

Bitcoin Core version v22.0.0 (release build)
...
ERROR: DeserializeDB: Deserialize or I/O error - Unsupported format of addrman database: 4. It is compatible with formats >=4, but the maximum supported by this version of Bitcoin Core is 3.: iostream error
Recreating peers.dat

or going back even further:

Bitcoin Core version v0.20.1 (release build)
...
ERROR: DeserializeDB: Deserialize or I/O error - Incorrect keysize in addrman deserialization: iostream error
Invalid or missing peers.dat; recreating

ACK d891ae768185b464cae476c16c74c365372d4a3c

I tested #23306 which is essentially the same:

1. Start latest code (with and without this PR) and use addpeeraddress RPC to create peers.dat with duplicates (either V3 or V4)
2. Recompile 92617b7~ and start it on the new peers.dat

It works as expected.

Concept ACK