dirty_update_counter returned the wrong value when a subscriber existed
and no events was sent. Thanks Anton Ryabkov.

Bad timing could lead to hanging transactions after a mnesia down from a
node with sticky locks.

Excellent bug report from janchochol

Situation:
* node A and B have copies of table T
* node A ows sticky of table T
* node A goes down (e.g. crash)
* node B tries to perform transactional operation on table T
  (e.g. mnesia:select)

In this situation there is possibility that first (and maybe other)
transaction on node B will hang indefinitely.
This is caused by race condition, when transaction process send lock
request operation to node A and waits for reply. When node A is down
it will never send reply, so process on node B will be stuck
forever.
Reason is that message sent to mnesia_locker gen_server from
mnesia_locker:mnesia_down can be received after mnesia_locker gen_server
already replies to transaction processes with {switch, N, Req} and
node N is down.
Monitoring remote process when sending request to other node should
be safe solution.

Avoid hanging waiting for other processes on other node
to commit.

Fixed a race where some parts of a transaction could
be added to the checkpoint.

There are probably more races here but this improves the current
testcases.

We don't support communicating with such old nodes anyway.

* nm/mnesia_idx_insert_speedup/OTP-11103:
  Fix missing case clause for ordered_set tables
  Optimize index creation for Mnesia set tables

The previous commit contained a regression that would trigger a crash
when attempting to add an index to an Mnesia table of type ordered_set.