The second call to connection.scalar() inside of _connect_ping_listener()
is not subject to the exc_filters system under SQLAlchemy 0.9 and earlier,
in the case that the attempt to revalidate within fails. This causes
the exception to be propagated outwards as the original
OperationalError (assuming that's what the DBAPI raised, as is typical),
rather than it being wrapped again in DBConnectionError.
SQLAlchemy 1.0 has altered this behavior such that the handle_error()
listener is invoked correctly for revalidiation attempts (it was being
invoked before, but without the correct state), as well as
for initial connect attempts, as part of
https://bitbucket.org/zzzeek/sqlalchemy/issue/3266/. For 0.9 and earlier,
we here backport this system into oslo/db/sqlalchemy/compat.py,
including that we redefine the connection pool's handler to re-throw
the original dbapi.Error instance directly, then move the handling
of this error in terms of SQLAlchemy wrapping and events into
the Engine and Connection. The approach here works back to
SQLAlchemy 0.8, and is conditional based on whether or not
SQLAlchemy 1.0 is detected.
Change-Id: I455e957b043318a8500909c66cadde53228b52d6
046e576467