With deferred DELETEs enabled, `space.delete()` writes the DELETE
statement to the primary index write set only while statements for
secondary indexes are generated either when the transaction is prepared
(if the deleted tuple is found in the memory layer or cache) or on
compaction.

Now imagine the following scenario:

1. There are tuples `{1,1}` and `{2,2}` in the memory layer of a space
   with enabled deferred DELETEs, the primary index over field 1, and
   a unique secondary index over field 2.
2. A transaction deletes `{2,2}` by the primary key and blocks on WAL.
   When the statement is executed, the DELETE statement is written only
   to the primary index write set because of enabled deferred DELETEs,
   but when the transaction is prepared (`vy_tx_prepare()`),
   the corresponding statement for the secondary index is generated
   because the deleted tuple is found in the in-memory layer, see
   `vy_tx_handle_deferred_delete()`.
3. In the meantime, another transaction replaces `{1,1}` with `{1,2}`
   and yields execution. It doesn't violate the unique constraint of
   the secondary index because `{2,2}` was deleted although not yet
   confirmed.
4. Imagine a transient WAL error happens and the first transaction is
   rolled back. The second transaction must be aborted too in this case
   because it implicitly read the DELETE statement prepared but not
   confirmed by the first transaction, but it is successfully committed,
   resulting in the unique constraint violation!

When a transaction is rolled back due to a WAL write error, we do
abort all transactions that read statements prepared by it, see
`vy_tx_rollback_after_prepare()`, but to do that, we iterate over
statements that were inserted into the transaction write set.
The problem is, we don't insert deferred DELETE statements generated
when a transaction is prepared in `vy_tx_handle_deferred_delete()` into
the write set because we don't need them for lookups at that point.
As a result, we don't abort transactions that read deferred DELETE
statements from secondary indexes.

Let's fix this issue by aborting all dependent transactions for each
statement inserted/deleted from the LSM tree. We already loop over
all transaction statements in `vy_tx_rollback_after_prepare()` and
`vy_tx_prepare` so there's no need to iterate over the write set entries
separately.

There's another related issue that may result in the same anomaly.
The problem is that we don't track the non-matching primary index
statement in the transaction write set when we look up the full tuple
by a key found in a secondary index, see `vy_get_by_secondary_tuple()`.
Normally, this is fine because we don't care if the primary index
statement is overwritten - we never returned it to the user. However,
if the statement hasn't been confirmed, it may still be rolled back
due to a WAL error reinstantiating the tuple matching the secondary
index key and making the lookup invalid. Note that this may happen
only if generation of the deferred DELETE is postponed to compaction.
Let's fix this issue by tracking unconfirmed primary index statements
in `vy_get_by_secondary_tuple()` even if they don't match the secondary
index key.

Closes tarantool#11969

NO_DOC=bug fix