Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd

Integrated support for asyncpg's ``terminate()`` method call for cases
where the connection pool is recycling a possibly timed-out connection,
where a connection is being garbage collected that wasn't gracefully
closed, as well as when the connection has been invalidated. This allows
asyncpg to abandon the connection without waiting for a response that may
incur long timeouts.

Fixes: #8419
Change-Id: Ia575af779d5733b483a72dff3690b8bbbad2bb05
(cherry picked from commit 3b7e621aa728d9b01dbac4150e13ea2ef6af35a3)

This method I would assume got committed during the
1.4 engine refactor, where we moved from different kinds of
ResultProxy implementations to different strategy
classes instead.   These strategies are set up by
dialects by setting "self.cursor_fetch_strategy"
in the execution context.   The method here was
likely a previous iteration of that which got merged
but was never used.

Change-Id: Iec292428f41c2c245bf7ae78beaa14786c28846c
(cherry picked from commit ec4a4910aa9ecc516cf3b096cb053fd9be7f82cc)

Added new method :meth:`.AdaptedConnection.run_async` to the DBAPI
connection interface used by asyncio drivers, which allows methods to be
called against the underlying "driver" connection directly within a
sync-style function where the ``await`` keyword can't be used, such as
within SQLAlchemy event handler functions. The method is analogous to the
:meth:`_asyncio.AsyncConnection.run_sync` method which translates
async-style calls to sync-style. The method is useful for things like
connection-pool on-connect handlers that need to invoke awaitable methods
on the driver connection when it's first created.

Fixes: #7580
Change-Id: I03c98a72bda0234deb19c00095b31a36f19bf36d
(cherry picked from commit 09ad975505adb2118f229cb5b1a75c2c412420ae)

Change-Id: Ic38dbc640aa0fe8a784a5b5e57c45a41eb0ea01b

Improve the interface used by adapted drivers, like the asyncio ones,
to access the actual connection object returned by the driver.

The :class:`_engine._ConnectionRecord` and
:class:`_engine._ConnectionFairy` now have two new attributes:

* ``dbapi_connection`` always represents a DBAPI compatible
object.  For pep-249 drivers, this is the DBAPI connection as it always
has been, previously accessed under the ``.connection`` attribute.
For asyncio drivers that SQLAlchemy adapts into a pep-249 interface,
the returned object will normally be a SQLAlchemy adaption object
called :class:`_engine.AdaptedConnection`.
* ``driver_connection`` always represents the actual connection object
maintained by the third party pep-249 DBAPI or async driver in use.
For standard pep-249 DBAPIs, this will always be the same object
as that of the ``dbapi_connection``.  For an asyncio driver, it will be
the underlying asyncio-only connection object.

The ``.connection`` attribute remains available and is now a legacy alias
of ``.dbapi_connection``.

Fixes: #6832
Change-Id: Ib72f97deefca96dce4e61e7c38ba430068d6a82e

Also replace http://pypi.python.org/pypi with https://pypi.org/project

Change-Id: I84b5005c39969a82140706472989f2a30b0c7685

Current effort is around the stub package, and having typing in
two places makes thing worse, since the types here are usually
outdated compared to the version in the stubs.

Once v2 gets under way we can start consolidating the types
here.

Fixes: #6461

Change-Id: I7132a444bd7138123074bf5bc664b4bb119a85ce

Change-Id: I488c9557eda390e4a88319affd4c8813ee274f80

The :meth:`_engine.Dialect.has_table` method now raises an informative
exception if a non-Connection is passed to it, as this incorrect behavior
seems to be common.  This method is not intended for external use outside
of a dialect.  Please use the :meth:`.Inspector.has_table` method
or for cross-compatibility with older SQLAlchemy versions, the
:meth:`_engine.Engine.has_table` method.

Fixes: #5780
Fixes: #6062
Fixes: #6260
Change-Id: I9b2439675167019b68d682edee3dcdcfce836987