Move DB thread pooling to DB API loader

Fixes bug 1128605

The dbpool code in sqlalchemy session is the wrong place to implement
thread pooling as it wraps each individual SQL call to run in its own
thread.  When combined with SQL server locking, all threads can be eaten
waiting on locks with none available to run a 'COMMIT'.

The correct place to do thread pooling is around each DB API call.

This patch removes dbpool from sqlalchemy and creates a common DB API
loader for all openstack projects which implements the following
configuration options:

db_backend: Full path to DB API backend module (or a known short name if
            a project chooses to implement a mapping)
dbapi_use_tpool: True or False whether to use thread pooling around all
                 DB API calls.

DB backend modules must implement a 'get_backend()' method.

Example usage for nova/db/api.py would be:

"""
from nova.openstack.common.db import api as db_api

_KNOWN_BACKENDS = {'sqlalchemy': 'nova.db.sqlalchemy.api'}

IMPL = db_api.DBAPI(backend_mapping=_KNOWN_BACKENDS)
"""

NOTE: Enabling thread pooling will be broken until this issue is
resolved in eventlet _OR_ until we modify our eventlet.monkey_patch()
calls to include 'thread=False':

https://bitbucket.org/eventlet/eventlet/issue/137/

Change-Id: Idf14563ea07cf8ccf2a77b3f53659d8528927fc7
readd update.sh to address bootstrapping issue

Provide an easy way to people to run the update script even
in a brand new oslo-incubator tree.

(fix spelling error)

Change-Id: I8c8f6e1d2d988ca0fffa79a7d8e9a67cf8311e7f
Merge "Move DB thread pooling to DB API loader"
Don't s/oslo/base/ for files in the rpc lib.

This breaks some message envelope handling code and is not needed for
any of the source files in rpc/, so just avoid it.

Change-Id: I8519568be5102a5890ae5ed046d6fcebe9bbb198
Revert "Fast serialization of RPC envelopes for Kombu"

This reverts commit 22c497097b0d0bd461be40a7a03290aa0b4179f2.

I'm not convinced that this isn't just a micro-optimization when
compared to the rest of the work that a given OpenStack service performs
as the result of these messages.

The implementation is also problematic.  It depends on using a '\0' byte
as a separator and assumes that '\0' will not exist anywhere else in the
message.  This seems to be asking for trouble.  If future data could
ever have a '\0' in it, this will be broken.  Further, if a user could
get a '\0' in a message directly with user-supplied input, this could
result in a security vulnerability.

Lastly, this has a significant impact on consumers of notifications that
are outside of OpenStack code, which have been the primary use case of
notifications (Ceilometer is changing that to a degree).  I don't think
consumers of notifications should have to implement this deserialization
method.

Change-Id: Ib3163ca98f568bf9f789d4b64bcc6d72e0fcb459
Revert "Implement replay detection."

This reverts Ib0260a0c62e3d312d2e3448a125bed64d861319e (commit a603678)

The issue we're trying to fix here is bug #1107064 - when using mirrored
queues with AMQP, acks can be lost while a master is failing over to a
slace causing the new slave to re-send messages which had previously
been acked.

The "replay detection" code applies to more than just amqp and also has
the appearance of a security measure (e.g. the use of the term 'nonce')
when clearly it serves no security purpose until we actually have
message signing.

Revert the "replay detection" approach in favour of the more targetted
amqp bugfix.

Change-Id: I8b8d15835c8b4c85cd388f5df08b60ff4c74e38d
Merge "Don't s/oslo/base/ for files in the rpc lib."
Merge "Revert "Implement replay detection.""