in order to remove LegacyRow / LegacyResult, we have
to also lose close_with_result, which connectionless
execution relies upon.

also includes a new profiles.txt file that's all against
py310, as that's what CI is on now.  some result counts
changed by one function call which was enough to fail the
low-count result tests.

Replaces Connectable as the common interface between
Connection and Engine with EngineEventsTarget.  Engine
is no longer Connectable.  Connection and MockConnection
still are.

References: #7257
Change-Id: Iad5eba0313836d347e65490349a22b061356896a

most of the work for aliased / from_joinpoint has been done
already as I added all new tests for these and moved
most aliased/from_joinpoint to test/orm/test_deprecations.py
already

Change-Id: Ia23e332dec183de17b2fb9d89d946af8d5e89ae7

An extra layer of warning messages has been added to the functionality
of :meth:`_orm.Query.join` and the ORM version of
:meth:`_sql.Select.join`, where a few places where "automatic aliasing"
continues to occur will now be called out as a pattern to avoid, mostly
specific to the area of joined table inheritance where classes that share
common base tables are being joined together without using explicit aliases.
One case emits a legacy warning for a pattern that's not recommended,
the other case is fully deprecated.

The automatic aliasing within ORM join() which occurs for overlapping
mapped tables does not work consistently with all APIs such as
``contains_eager()``, and rather than continue to try to make these use
cases work everywhere, replacing with a more user-explicit pattern
is clearer, less prone to bugs and simplifies SQLAlchemy's internals
further.

The warnings include links to the errors.rst page where each pattern is
demonstrated along with the recommended pattern to fix.

* Improved the exception message generated when configuring a mapping with
  joined table inheritance where the two tables either have no foreign key
  relationships set up, or where they have multiple foreign key relationships
  set up. The message is now ORM specific and includes context that the
  :paramref:`_orm.Mapper.inherit_condition` parameter may be needed
  particularly for the ambiguous foreign keys case.

* Add explicit support in the _expect_warnings() assertion for nested
  _expect_warnings calls

* generalize the NoCache fixture, which we also need to catch warnings
  during compilation consistently

* generalize the __str__() method for the HasCode mixin so all warnings
  and errors include the code link in their string

Fixes: #6974
Change-Id: I84ed79ba2112c39eaab7973b6d6f46de7fa80842

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

Change-Id: I84b5005c39969a82140706472989f2a30b0c7685

Fixed issue in experimental "select ORM objects from INSERT/UPDATE" use
case where an error was raised if the statement were against a
single-table-inheritance subclass.

Additionally makes some adjustments in the SQL assertion
fixture to test a FromStatement w/ DML.

Fixes: #6591
Change-Id: I53a627ab18a01dc6d9b5037e28312a1177891327

a new segfault is observed in python 3.10.0b2 in conjunction
with asyncio and possibly greenlet.   Ensuring the
traceback object is deleted from scope here, which is a
good idea anyway, apparently seems to resolve the issue.

Change-Id: Ia83bafb088ef19853044f1d436db259cbfd1e5f4
References: https://github.com/python-greenlet/greenlet/issues/242

Fixed regression where the introduction of the INSERT syntax "INSERT...
VALUES (DEFAULT)" was not supported on some backends that do however
support "INSERT..DEFAULT VALUES", including SQLite. The two syntaxes are
now each individually supported or non-supported for each dialect, for
example MySQL supports "VALUES (DEFAULT)" but not "DEFAULT VALUES".
Support for Oracle is still not enabled as there are unresolved issues
in using RETURNING at the same time.

Fixes: #6254
Change-Id: I47959bc826e3d9d2396ccfa290eb084841b02e77

Fixed issue where a "removed in 2.0" warning were generated internally by
the relationship loader mechanics.

This changeset started the effort of converting all string usage
in the test suite, however this is a much longer job as the
use of strings in loader options is widespread.  In particular
I'm not totally comfortable with strings not being accepted
in obvious spots like Load(User).load_only("x", "y", "z"), which
points to a new string expecting functionality that's not
what's there now.  However at the moment it seems like we need
to continue removing all support for strings and then figure out
"immediate strings from an explicit class" later.

Fixes: #6115
Change-Id: I6b314d135d2bc049fd66500914b772c1fe60b5b3

Fixed regression where :meth:`_orm.Query.join` would produce no effect if
the query itself as well as the join target were against a
:class:`_schema.Table` object, rather than a mapped class. This was part of
a more systemic issue where the legacy ORM query compiler would not be
correctly used from a :class:`_orm.Query` if the statement produced had not
ORM entities present within it.

Also repair the assert_compile() method, which was using
Query._compile_state() which was bypassing the bug.   A handful
of ORM tests with Query objects and Core-only objects were actually
failing if the default compilation path were used.

Fixes: #6003
Change-Id: I97478b2d06bf6c01fe1f09ee118e1f2ac4c849bc

We are unfortunately stuck with this class completely
until we get rid of "dynamic" altogether.    The usage
contract includes the "query_class" mixin feature where
users add their own methods, and this use case  very
well in line with 2.0's contract.  As Query is not going away
in any case this has to stay in "legacy" style, there's no
point trying to change it as the new version was still fully
dependent on Query.

Fixes: #5981
Change-Id: I1bc623b17d976b4bb417ab623248d4ac227db74d