ops

Do a proper roll back on dump/compact failure.

Now, names of related interfaces, global variables and
fields are based on "iterator".

This is pure refactoring without any functional changes.

Closes #1694

The range iterator open function used an obsolete indicator
for special key (NULL key), which led to selection of a wrong
range in :max() query.

The bug required a compaction process to trigger it, since
when there was only 1 range max() naturally always got the last one.
After compaction, range iterator open could yield a random
range for the special key.

Update errinj.test.lua to always trigger compaction.

Remove all ranges from scheduler before deleting index.

Follow up 43ca199e

The merge iterator didn't take into account iterator diretion
when merging its sources, and always used to return the smallest
tuple among the alternatives.

If iterator order is LT or LE, the biggest tuple should be returned
instead.

We don't remove dead index's ranges from the scheduler heap after we
scheduled a drop task for it - we only do it from the drop task itself.
As a result, we can happily go and schedule another task for the index
being already scheduled for destruction. This can result in the
index->ref == 1 assertion being violated in vy_task_drop_execute() or
memory corruption induced by use-after-free of a vy_index struct.

Switch to pointers from built-in structures range->i[01].

* add a test case based on error injection
* fix a few release mode warnings
* the test case is still failing, depends on introduction of shadow
memory indexes.

Use global queues for scheduling instead of per-index.

Fixes #1708

Update test run (fixes the sporadic console handshake bug when running
tests).

Fixes gh-1163.

Closes #1599

Don't access uninitialized memory in ev_io_closing().

anfds array is initialized with zeroes, when it's reallocated,
but anfdmax is array size, not array last element, so
anfds[anfdmax] is garbage.

When we're "closing" an fd which has never been added
to anfds (ev_io_start()) wasn't called for it), we
must check that it's within array size boundaries first.

Since range_id_max is not updated, indexes created after recovery might
get the same ids as recovered ones. If this happens, the next recovery
will crash, because there will be two or more identical ids in the range
index file.

Prepare for #1599

vy_range_redistribute() doesn't work correctly if ranges are not sorted
in ascending order.

vy_task_{dump,compact}_{execute,complete} serve as trivial wrappers for
the functions doing real work. Let's fold them to make the code more
straightforward. No functional changes intended.

While we touch this code, let's also get rid of all the pointless
unlikely's - after all the functions are not called from hot paths so
there's no point in cluttering the code.

This is pure refactoring, isn't supposed to introduce any functional
changes.

It is only set and never checked.

vy_range_lock() is used in order to forbid scheduling two dump or
compact operation on the same range, so there's no point in locking and
then unlocking new ranges on compact completion, because it is run from
the same thread as the scheduler. This is a legacy of the past, when
vy_range_compact_commit() was called from a worker thread. Zap it.

It's not good to mess them all together in one struct. Let's use a
union.

Take into account all runs and in-memory index.

Follow up bfe23238

Add a test case for automatic cursor close on transaction
commit/rollback.
Fix a coding bug this test exposed.
Update comments.

Add a test case for gh-1606 "visibility of changes made
by a transaction in range queries".

These ara basic tests for transaction write set
iterators implemented by @a_lyapunov

As there is ->complete available now, we can release quota from there.