XtraDB Priority RW Lock

Implement a priority RW lock, which differs from the regular RW lock in wake up / acquisition policies. This is analogous to the priority mutex [1], but shares no code with it. Several design points are shared with it: only safe to be used when we are certain indefinite starving cannot occur; there exists a time window where a low priority acquirer may overtake high priority waiters through spinning; implemented as new C++ overloads for the existing RW lock API to minimize code changes; do not blanket-convert all the RW locks to be priority. These points are elaborated in [1].

The RW lock waiter priorities are ordered as follows 1) high priority next-writer waiter; 2) regular priority next-writer waiter; 3) high priority X waiters; 4) high priority S waiters; 5) regular priority waiters. The regular priority next-writer waiters has higher priority than we'd ideally prefer, but it's inherent in the current design. This may be addressed in the future if needed.

Since, in contrast to the priority mutex, all waiter prioritization is implemented through waiter presence flags, also use them to skip spin loops on a new low priority requests when there are high priority waiters already. This is needed both for performance (skip the redundant spinning) and correctness. The correctness issue is that, a sequence of overlapping regular priority S requests may starve a high priority X request indefinitely. This is addressed by skipping spinning even if a regular priority S request could be granted.

The granularity of such checks is coarse now, erring on the side of behaviour of regular RW lock. A future tuning might change this.

Convert the following locks to be priority: fsp, page_hash, AHI, index, purge.

For RW locks in MTR, exploit the facts that all the locks that are used in MTR are converted to priority, thus patch the existing functions mtr_release_s_latch_at_savepoint(), mtr_s_lock_func(), and mtr_x_lock_func() instead of providing new overloads. Also make MTR_MEMO_S_LOCK and MTR_MEMO_X_LOCK to assume that the memo slot object is a priority rw lock, to avoid introducing new MTR memo slot types.

[1] https://blueprints.launchpad.net/percona-server/+spec/xtradb-priority-mutex