The applier fiber can get blocked while waiting for journal
submit, if the journal queue is full.

While waiting, the applier can get cancelled (for example, when
its peer is removed from box.cfg.replication).

This produced the error code JOURNAL_ENTRY_ERR_CANCELLED for the
transaction's signature, which wasn't handled on its
transformation into an error object in
diag_set_journal_res_detailed(), causing a panic-crash.

There was only one place, where this error code wasn't immediately
transformed into an error object and had to be carried via the
signature code: applier_rollback_by_wal_io().

The design of this function having to create an error object
before txn_commit_submit() returns is probably questionable, but
not big enough of a problem to redesign it right now.

Closes #12719

NO_DOC=bugfix

Instance with election_mode='off' still allows box.ctl.promote().

This was a mistake to enable this in the public API, but it is
already done, and deprecation will take a long while.

From user's PoV such usage of synchronous replication looks
deceitfully convenient, but is very dangerous as it will
sporadically result into split-brain errors even when the leader
election works completely smooth. This will stay. And the reason
for such behavior is that elections with election_mode='off'
effectively use election quorum 1. No matter what
replication_synchro_quorum is configured to.

From dev's PoV the biggest pain was that with off-mode the limbo
had to ignore the Raft state machine. It manifested in many places
in the code as having to check raft_is_enabled() being true or
false.

In the future it would be very hard to make this hack co-exist
with the synchronous promotions. It would bloat the branching on
raft_is_enabled() and its corner cases even more.

The current patch does a simple thing - makes limbo and Raft
work literally like the high-level observable behavior of
promotions with election_mode='off'. Which means - use election
quorum 1 and txn confirmation quorum as configured.

Then Raft being always enabled (after recovery is complete) is
actually ok, and makes the code way simpler, allowing to eliminate
tons of corner cases and hacky checks, while preserving most of
the (buggy by design) behavior.

It will also be able to co-exist with the synchro promotions, as
these new promotion entries in the future will simply use the
election_quorum (= 1 in case of 'off' mode), and hence will work
like before.

Nonetheless some behavior changes might still be observed. Could
be considered bug fixes. Specifically, now even with
election_mode='off':

- on WAL error the leader will resign.

- box.info.ro_reason "election" is deleted, only "synchro"
  remains.

- box.info.election.state will show 'leader' when the instance is
  actually the leader.

- switching 'off' -> 'manual'/'candidate' will preserve the
  leadership state without need for new term elections (if the
  instance was actually the leader).

- some error messages about concurrent or conflicting elections
  might be different.

- box.ctl.demote() requires the node to own the limbo in the
  latest known Raft term. If Raft term is newer than the limbo,
  then it is too unsafe to allow persistent demotion. The node
  must firstly promote itself and then can do the demotion.

- the node will be able to vote, when it receives a vote request
  and the candidate looks suitable. Previously the inability to
  vote could result into candidate-nodes being unable to win any
  elections, because the off-nodes are still counted towards
  quorum 50% + 1 (they are in `_cluster` space), but if they never
  vote and there is more than half of them, then no candidate-node
  would ever win any elections.

Part of #8095

@TarantoolBot document
Title: `election_mode` update

Here: https://www.tarantool.io/en/doc/latest/reference/configuration/#confval-election_mode.

The doc says that the `election_mode='off'` makes it not
participate in the election process, and it won't run the Raft
state machine.

But it is gonna change. Need to update the text between
"Possible values" and "Since version 2.8.2, .....".

Like this:
```
Participation of a replica set node in the automated leader
election can be configured with this option.

The default value is `'off'`.

All nodes run the Raft state machine internally, talking to other
nodes according to the Raft leader election protocol. All nodes
can vote for other nodes in elections and ack synchronous
transactions except for anonymous replicas (they are basically
ignored by elections and synchronous transactions ack counting).

When the mode is `'off'`, the node can be writable even when it is
not the leader. Normally in this state the Raft state machine is
just idle on all the nodes, and the leadership management is done
externally (if done at all).

If in `'off'` mode the node sees the synchronous transaction queue
claimed by any node (`box.info.synchro.queue.owner` is not 0),
then it will be read-only unless it is the owner of the queue and
is the elected leader.

To disable synchronous replication entirely and to be able to make
nodes writable regardless of Raft and the synchronous transaction
queue you can switch into `'off'` mode, and then do
`box.ctl.promote()` + `box.ctl.demote()`.

The mode `'off'` is mostly just a way to run asynchronous
replication, and also a way to get off the synchronous
replication. It must not be used for actual production workload as
it can result into split-brain errors even in a seemingly healthy
replicaset.

The usage ways are normally either mode `'off'` on all nodes and
no `box.ctl.promote()` at all, or election modes `'voter'`,
`'candidate'` and `'manual'` on all nodes and full reliance on the
synchronous replication and Raft elections.

When a node is a `'voter'`, it will be able to vote, but will not
be a leader. It will also be read-only guaranteed.

When a node is a `'candidate'`, it will watch the state of the
current leader, and will actively try to get itself elected when
the leader is not healthy.
```