Reintroduce tracking of active transactions on master side

to fix an issue where locks could get stuck. The problem was that a
rollback on the slave due to lock timeout would go over to the master and
end the lock session too early, before the last acquiring thread might
have finished its waiting. So when the pending lock acquisition would
complete the lock would be registered and then never released since the
lock client had already been closed.

With this commit, when the slave rolls back, the lock session on the master will be
closed if there is no thread awaiting a lock acquisition. If there is a
thread awaiting a lock acquisition the session will just be marked as
"please finish asap" and the session reaper will close it as soon as the
lock acquisition has completed.

This exact behaviour existed in 2.1 and in previous versions, but was
removed by mistake in 2.2 due to suboptimal understanding of the scenario
described above.
Merge pull request #2888 from tinwelint/2.2-lock-stuck-issue

Reintroduce tracking of active transactions on master side