Also provide handler::is_using_full_key

The original parameter comes from
commit a869c56d361bb44f46c0efeb11a8f03561676247
write/sync redo log before flushing binlog cache to file

we've already disabled some of that patch in
8cde1d44

cset
c2b8ced16e255ffdbcc1e638ac8dd4f398eb1a93
Implement START TRANSACTION WITH CONSISTENT INNODB SNAPSHOT

Should we start supporting it?

It is from "write/sync redo log before flushing binlog cache to file"
feature that MariaDB doesn't have (or need?)

adjust a few function definitions accordingly

Then Regex_list_handler is not needed and we don't have to backport
it right now.

And the code in ha_rocksdb.cc makes assumptions about hidden pk length
being 8, anyway.

(Squash with 4be8cae5)

"Add new function my_hash_const_element(), the const equivalent of
my_hash_element()" - comes from facebook/mysql-5.6,
7c869d34b9fa2262b941efd6363a260b7c37948f

Probably this is not the right way to do it, see the comment

(why are table reads/writes/updates collected in ha_statistics?
this structure was intended for table statistics that the engine
reports.. and now it is also used for engine-agnostic statistics
like rows_read, rows_requested, etc?)

Flashcache is available only in WebScaleSQL (not in MySQL or MariaDB).

They have been replaced with increment_statistics() calls made
by handler::ha_XXX() methods.

Issue #108: Index-only scans do not work for partitioned tables and extended keys
c1f1f0b64eaecd132fc6ec21663faf0510afacaf

Leave the code in, but #ifdef it away to avoid compilation
error

Rdb_atomic_perf_counters uses my_io_perf_atomic_struct
which uses atomic_stat from include/atomic_stat.h
which was backported in the previous cset.

commit b5fda565d4bad66f3b5a6432236b96743ccfd323
Author: Steaphan Greene <steaphan@fb.com>
Date:   Fri Feb 7 21:34:04 2014 -0800

    Add basic atomic_stats type

    Summary:
    WebScaleSQL Feature: Basic Stats Support

    This is a simple class template that implements an atomic stats variable.

    The focus is on performance, not accuracy.  No set operations are
    guaranteed.  The other operations are all atomic, so values should not
    actually be lost - however, there is no attempt to be consistent in
    reading multiple stats, nor any concern that different threads see any
    consistent view across multiple stats.

    Test Plan:
    This has been tested quite a bit in isolation, and no problems have been
    found.  However, this has never been used in production.  Also, a newer,
    more sophisticated, version of this is already in development.

    It also shows a small perf gain in the larger stats diffs (Table Stats,
    User Stats, etc...), when compared to the built-in MySQL atomics.

    Reviewers: pivanof

    Reviewed By: pivanof

    CC: jtolmer, MarkCallaghan, flamingcow, jeremycole, andrew-ford, inaam-rana, liang.guo.752

    Differential Revision: https://reviews.facebook.net/D16029
    Differential Revision: https://reviews.facebook.net/D16449

Got to the point where we fail when compiling MyRocks files.