WL#8149: B-tree Index Support on non-materialized virtual columns

Status: Complete

This worklog implements creating secondary indexes on non-materialized virtual
columns (let's simplify it as "virtual index") as well as using such indexes for
fast computed-value retrieving and searching. The non-materialized virtual
column support is described in WL#8114 and WL#411, which design the
virtual column in such way that they are not present in actual InnoDB index
records, but their metadata is registered with InnoDB system tables and
metadata caches.

Virtual column provides flexibility and space saving on the table, more
importantly, adding/droping such columns does not require table rebuild. Making
it a much better choice for storing and processing non-relational data such as
JSON. However, since they are not materialized, the scan/search could be very
slow. With this worklog, the virtual column value will be materialized in the
secondary index, making it much easier for value search and processing.

This worklog implements following major functionalities:

1) Create index on non-materialized virtual columns. User can create secondary
index on one or more virtual columns. And since this is a secondary index, and
also the columns are not materialized, adding/dropping columns and creating
index does not require a table rebuild, which is way better than the
materialized virtual column. (WL#8114 covers ADD/DROP COLUMN for virtual columns.) 

2) User is able to search qualified rows using such "virtual indexes", both in
terms of non-covered and covered scan. When searching such an index, no
computation is needed, because the value is materialized in the index record
and in undo log records. Also this should support all MVCC look ups by following
up cluster index and its "earlier versions".

3) Such "virtual index" gets updated correctly for DMLs, as well as any
transactional commits and rollbacks.

4) Such "virtual index" maintains its coherence during all crash recovery with
sufficient operational undo and redo logging.

5) Such "virtual index" should support all isolation level searches
and locking like using any other "normal" index

6) Such "virtual index" should be able to work with large BLOB/TEXT data in
their "base" column. The index key size is goes with their original limit (767
bytes for Antelope, 3072 for Barracuda format)

In summary, the "virtual index" is an essential means to efficiently use virtual
columns, without levy heavy computation and table scan for value searching and
other DML actions.