There are a number of arguments to deprecate triggers on recovery:

- One has to write triggers with this peculiarity in mind. For example, if
a trigger is used for some kind of data exporting, it should be skipped
during recovery because the data must have already been exported before
restart.

- These triggers do not work with other engines. For example, in case of
Vinyl, the behavior is undefined: a trigger may or may not run for
a statement recovered from an xlog, depending on whether it was dumped
to disk before restart.

- Using `before_replace` triggers on recovery is dangerous because it may
break recovery. Even if it doesn't, one may get a database state, in
which the in-memory data is different from on-disk data, which may
result in weird breakages later.

- Supporting triggers on recovery slows down startup because we have to
run all statements recovered from the snapshot through the transaction
manager, see tarantool#11452 (Recovery performance regression (-1.5x on SSD)).

- Handling the triggers complicates our code. We have to disable certain
features if triggers are set, e.g. see tarantool#10847 (Save order of secondary
indexes to snapshot).

Now if `compat.box_recovery_triggers_deprecation` is 'new' we do not
trigger space and transactional events during recovery.

Closes tarantool#11756

@TarantoolBot document
Title: Deprecate triggers during recovery

Deprecate space and transactional triggers during recovery.

(Please create https://tarantool.io/compat/box_recovery_triggers_deprecation)

We are planning to switch the compat option to the new behavior starting
from Tarantool 4.0 with the ability to revert to the old behavior.
Starting from Tarantool 5.0 there will be no option to trigger events
during recovery.