Trivial fil_space_t::n_pending_ops transition. Since it is not
obvious which memory barriers are supposed to be issued, seq_cst
memory order was preserved.

buf_pool_t::n_pend_unzip transition to Atomic_counter.

zip_pad_info_t::pad transition to Atomic_counter.

ibuf_t::n_merged_ops and ibuf_t::n_discarded_ops transition to
Atomic_counter.

buf_block_t::n_pointers transition to Atomic_counter.

Trivial fil_space_t::n_pending_ios transition. Since it is not
obvious which memory barriers are supposed to be issued, seq_cst
memory order was preserved.

Almost trivial ReadView::m_state transition. Since C++11 doesn't seem to
allow mixed (atomic and non-atomic) access to atomic variables, we have
to perform all accesses atomically.

srv_sys_t::n_threads_active transition to Atomic_counter.

Almost trivial TTASFutexMutex::m_lock_word transition. Since C++11
doesn't seem to allow mixed (atomic and non-atomic) access to atomic
variables, we have to perform all accesses atomically.

Closes #986

Remove an unused variable, and propagate the error to the caller
instead of calling exit().

dict_table_t::rollback_instant(): Restore dict_index_t::n_core_fields.

Added lf_hash_size() macro, so that callers don't need to use atomic
operations.

Simplified worker threads completion waiting, made it use std::atomic.

This is follow-up patch. Avoid calling constructor/destructor twice.

This is a follow-up to commit 9581c4a8
which added a memcpy() call to rtr_copy_buf(), to copy
rw_lock_t debug_latch. This could emit a warning.

A cleaner approach is to make buf_block_t::debug_latch a pointer,
so that we can avoid copying it. An even cleaner approach would be to
redesign the InnoDB SPATIAL INDEX code so that the function
rtr_copy_buf() is not needed at all.

avoid calling SSL_get_verify_mode() and  SSL_get_verify_depth(),
since yassl implementation of the function accesses the acceptor context,
which can be freed on FLUSH SSL command.

purge_sys_t::m_enabled transition to std::atomic.

enabled_latched() doesn't make much sense: in this particular case it is
as fast as atomic load. The sole caller has to reload it's value anyway,
due to rw_lock_x_lock(&purge_sys.latch) issuing acquire memory barrier.

When purge_sys_t::close() is reached, m_enabled must be false, otherwise
we may free members, which are still in use by the coordinator thread.

purge_sys_t::m_paused transition to Atomic_counter.

paused_latched() doesn't make much sense: in this particular case it is
as fast as atomic load. The sole caller has to reload it's value anyway,
due to rw_lock_x_lock(&purge_sys.latch) issuing acquire memory barrier.

onlineddl_rowlog_rows transition to Atomic_counter.

os_aio_validate_count transition to Atomic_counter.

ibuf_t::n_merges transition to Atomic_counter.

dict_table_t::n_foreign_key_checks_running transition to
Atomic_counter.

trx_sys_t::rseg_history_len transition to Atomic_counter.

fil_space_t::redo_skipped_count transition to Atomic_counter.

srv_conc_t.n_active and srv_conc_t.n_waiting transition to
Atomic_counter.

btr_defragment_compression_failures, btr_defragment_failures and
btr_defragment_count transition to Atomic_counter.

os_thread_count transition to Atomic_counter.

Almost trivial rw_lock_t::waiters transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform atomic initialisation.

Almost trivial rw_lock_t::lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform atomic initialisation.

Also made previously broken code in gis0sea.cc even more broken. It is
unclear how it was supposed to work and what exactly it was supposed to
do.

os_total_large_mem_allocated transition to Atomic_counter.

Replaced simple_atomic_counter with Atomic_counter.

Trivial buf_tmp_buffer_t::reserved transition.

Relaxed memory order looks suspicious when used by methods that have
acquire()/release() names. Especially if intention is to transfer some
variable or memory region from one thread to another. Or is memory
ordering guaranteed by something else, e.g. some mutex that protects
broader range of acquire/release functionality?

Almost trivial TTASEventMutex::m_lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform all accesses atomically.

Almost trivial TTASMutex::m_lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform all accesses atomically.