Given that after recent item sync is done (if it's needed at all), the
range set reconciliation algorithm no longer depends on newly received
item being added to the set, we can save memory by not adding the
received items during reconciliation.

During real sync, the received items will be sent to the respective
handlers and after the corresponding data are fetched and validated,
they will be added to the database, without the need to add them to
cloned OrderedSets which are used to sync against particular peers.

This adds multi-peer synchronization support.
When the local set differs too much from the remote sets,
"torrent-style" "split sync" is attempted which splits the set into
subranges and syncs each sub-range against a separate peer.
Otherwise, the full sync is done, syncing the whole set against
each of the synchronization peers.
Full sync is also done after each split sync run.
The local set can be considered synchronized after the specified
number of full syncs has happened.

The approach is loosely based on [SREP: Out-Of-Band Sync of
Transaction Pools for Large-Scale
Blockchains](https://people.bu.edu/staro/2023-ICBC-Novak.pdf) paper by
Novak Boškov, Sevval Simsek, Ari Trachtenberg, and David Starobinski.

The `sqlstore` package provides simple sequence-based interface to the
tables being synchronized. It is used by the FPTree data structure as
the database layer, and doesn't do range fingerprinting by itself.

`SyncedTable` and `SyncedTableSnapshot` provide methods that wrap the
necessary SQL operations. `sql/expr` package was added to facilitate
SQL generation.

It didn't add much to efficiency

Re-generating SQL statements every time is quick but increases GC
pressure.