It was previously only available directly in WAL API. This forced
the checkpoint build code to rely on WAL, breaking the journal's
API encapsulation.

While now it is not a big deal, it is going to become one in the
next commits, where the checkpoint build code is moved into
another place not having WAL as a dependency. Lets not drag WAL
there and generalize the journal checkpoint API.

Needed for #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

Those files were about atomic build of the "global checkpoint" of
all transaction-related control states with no observable
after-effects (nothing changed on disk and in any of those control
states).

But this code conveniently contains a lot of intricate steps which
could be reused for an on-disk checkpoint creation (snapshot).

That would turn it into something bigger than just "txn"
checkpoint. Lets prepare to that by firstly renaming the files.

The next commit will change the contents. It is separated from the
file rename in order not to confuse git into thinking that the
old txn_checkpoint files are rewritten from scratch.

Needed for #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

txn_checkpoint was about atomic build of the "global checkpoint"
of all transaction-related control states with no observable
after-effects (nothing changed on disk and in any of those control
states).

But this code conveniently contains a lot of intricate steps which
could be reused for an on-disk checkpoint creation (snapshot).

That would turn it into something bigger than just "txn"
checkpoint. Lets prepare to that by renaming the struct and
related functions.

Needed for #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

box/checkpoint.h+c already contains the in-memory control states
checkpoint creation code.

Lets also move here the creation of the on-disk checkpoint. This
will make it easier to reuse the quite nontrivial common code
between these two kinds of checkpoints.

This commit though only moves the code and doesn't intend to make
any functional changes.

Part of #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

It contains the data that needs to be known by the specific
engines to create their checkpoints.

Previously it was only a flag, but now it also contains the
box_checkpoint object. This one will steal some work from the
memtx checkpoint in the next commits, but its data is still going
to be written into "memtx checkpoint" aka snapshot.

Part of #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

Previously the collection of it was done in the memtx code. But it
isn't done right and doesn't belong to just one engine.

Lets move this code into an engine-agnostic place, into
checkpoint.c. It is logically more natural and will allow to reuse
the existing code for in-memory checkpoint build.

The commit intends no functional changes and only moves the code,
so it would be easier to actually fix it in the next commit.

Part of #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

It is going to be needed higher in the file in the next commits.
Lets move it, so the next commits would only change a small part
in it instead of having a 100% diff it due to the move.

In scope of #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

There was a bug that the snapshot creation code would do the
synchronous transaction control state collection too early. It
was fully done even before the engines would begin their
checkpoints.

That led to a problem that the limbo and Raft checkpoints could
have outdated confirmation LSN, terms, and anything else that is
supposed to be written into the snapshot.

The easiest way to reproduce it was to just start a snapshot when
there is at least one pending synchronous transaction. Then the
snap file would get the old confirmation LSN, but would also have
this transaction's data.

That seemed not to lead to any noticeable and visible bugs except
when one explicitly reads the snapshot file and observes the old
LSN or a term. But that still didn't look safe.

The solution is to just collect these control states the same way
as the in-memory checkpoint is being collected.

Closes #11754

NO_DOC=bugfix

Previously the join/fetch-snapshot procedure would build
checkpoints of the global engine-agnostic states (like limbo,
raft, journal) right inside memtx_engine code.

That didn't look right for memtx to take care of such broad things
which really cover not only memtx. It also forced the relay to
pass into memtx some additional context via struct
engine_join_ctx.

Lets move those things out. It should be fine to do them right in
the relay code. That makes memtx join code more specific, and even
no longer forces memtx join code to be executed first (probably
it still should be, but for other reasons).

Follow up for #11754

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring