WL#3583: BLOB Locator API

Using BLOB Locators is a means of working with BLOBs that many other RDBMSs
support. This is a convenient and natural way to work with BLOBs in an
application, similar to working with normal files.

A BLOB Locator is similar to a FILE Handle, and in some cases the term BLOB
Handle is used.

A BLOB Locator is some kind of BINARY datatype that provides access to a single
BLOB in the database. Fetching a BLOB Locator will retreive just this handle,
not the BLOB itself. The locator is subsequenly used to provide access to the BLOB.

A BLOB Locator can, in addition to provide a means to access the BLOB, also
indicate attributes of the BLOB and/or the access to it. The reason for this is
that BLOBs are often treated differently from other data in the database, for
example in the case of transactions, for example a BLOB Locator might well be
transactional, whereas the BLOB is not. This minimize the size of the
transaction and still provides the full benefit of using BLOBs. Also, in some
cases, BLOB are transactional in a different context than the locator that
references this data.

Finally, as Locators are handled together with the data, but the BLOB itself is
not necessarily so, a BLOB might have multiple references or more references
than the data (i.e. if a row that reference a BLOB is DELETEd, but the BLOB is
currently in use by someone, then the row is delted, but the reference count in
the BLOB stays at 1, allowing any ongoing operations to complete before commencing).

The way I foresee this to be implemented is this:
- The existing C-API is complemented with the BLOB_LOCATOR datatype. From the C
API side, this is binary value of considerable length (64 bytes or so).
- The prepared statement API is extended to be able to describe a BLOB Locator
for both in and output.
- A separate set of API functions for BLOB Locators is added.
- Information functions are added to check if:
-- Locators can be transactional / non-transactional or both.
-- Ability to set transactional state of BLOB Locators.
-- Ability to check for Locator support. Initially I expect the API to be
supported only by selected Storage Handles. Eventually I guess that we can
emulate there in the cases where it is not supported.

C API:
- mysql_get_server_blob_flags() - Returns flags telling if BLOB locators are
supported at all and other information about BLOB support on the server side.

C Prepared Statement API:
- BLOB_LOCATOR datatype.- Allows one to bind to a BLOB locator.
- mysql_stmt_bl_flags() - Get the BLOB capabilities for a statement. This is
necessary, as the capabilities of the different tables in a statement might be
different, and the combination might limit these capabilities for an individual
table.

C BLOB Locator API:
- mysql_bl_table_flags() - Get the BLOB relevant flags for a specific table,
like transactional capabilities and if BLOB support is in the engine or
"virtual" in the server (not yet supported).
- mysql_bl_create() - Create a BLOB locator
- mysql_bl_open() - Open a BLOB using a BLOB_LOCATOR binary and a set of flags
signifying the transactional state.
- mysql_bl_open_string() - Open a BLOB using a BLOB_LOCATOR represented as a
string from the normal C API. Returns a BLOB_LOCATOR.
- mysql_bl_seek() - Obvious use.
- mysql_bl_close() - Obvious use.
- mysql_bl_tell() - Obvious use.
- mysql_bl_read() - Obvious use.
- mysql_bl_write() - Obvious use.
- mysql_bl_flush() - Like a "commit" for a transactional BLOB.
- mysql_bl_get_refcount() - Number of references to the BLOB. Usually returns 1
or 2 with normal storarge engines, where BLOBs are handled just like normal
data. I.e. 1 for the current API and 1 for the referencing row. If a new BLOB,
the 1 an existing one will return 2, but any value can potentially be returned
if BLOB handling is separate from normal row handling.
- mysql_bl_commit() / mysql_bl_rollback() - These are a bit less obvious than
the ones above, but as we might have a case where transactions are handled
differently with BLOBs than other data, it might be a good idea to allocate
space for them. An example of where it might be a good to have BLOB and non-BLOB
transaction handlling different is in the case of multi-versioning. For BLOBs,
you might want to have a simple locking scheme, whereas you want MVCC with the
rest of the data.

Storage engine API:
The following flags are added, any or all of these might be supported:
- HTON_BLOB_LOCATOR - Engines that support BLOB Locators (supporting this in the
Stoarge Engine is what makes this really useful and cool) 
- A separate BLOB handlerton that is pointed to by the Stoarge Engine
handlerton. The reason for this is that the same BLOB handling code might be
shared between Storage Engines (which should be a pretty cool concept, and which
simplifies development as BLOB Locator code gets sepatared from the Storage Engine).
- The following flags for the BLOB handlerton are added:
* HTON_BLOB_TRANSACTIONAL - Flag that blobs may be transactional, but separate
from the normal transactional context.
* HTON_BLOB_NONTRANSACTIONAL - Flag that BLOBs are non-transactional.
* HTON_BLOB_DATA_TRANSACTIONAL - Flags that BLOBs are handled in the same
transaction as the data. A COMMIT means an implicit mysql_bl_close() on the BLOB.
- The BLOB handlerton has an init() method.
- The BLOB handlerton also contains basically the same methods that corresponds
to the BLOB Locator interface above.
- The BLOB handlerton might also optionally define commit() and rollback()
methods. These are then used when the is an implicit commit / rollback in the
enclosing Storage Engine.
- The BLOB handlerton might also have a few more methods, like a speratate
recovery function, backup function etc. This needs some more thinking, but that
is probably not necessary in a first implementation.