Also clarifies a behavior of None/False for the selectable
parameter to with_polymorphic()

Fixes: #7262
Change-Id: I58c4004e0af227d3995e9ae2461470440f97f252

Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I92013aad471baf32df1b51b756e86d95449b5cfd

Repairs one in-library deprecation warning regarding
mapper propagation of options

raises maxfail to 250, as 25 is too low when we are trying
to address many errors at once.   the 25 was originally
due to the fact that our fixtures would be broken after
that many failures in most cases, which today should not
be the case nearly as often.

Change-Id: I26affddf42e2cae2aaf9561633e9b8cd431eb189

a few changes for py2k:

* map_imperatively() includes the check that a class
  is being sent, this was only working for mapper() before

* the test suite didn't place the py2k "autouse" workaround
  in the correct order, seemingly, tried to adjust the
  per-test ordering setup in pytestplugin.py

Change-Id: I4cc39630724e810953cfda7b2afdadc8b948e3c2

Adjusted ORM loader internals to no longer use the "lambda caching" system
that was added in 1.4, as well as repaired one location that was still
using the previous "baked query" system for a query. The lambda caching
system remains an effective way to reduce the overhead of building up
queries that have relatively fixed usage patterns. In the case of loader
strategies, the queries used are responsible for moving through lots of
arbitrary options and criteria, which is both generated and sometimes
consumed by end-user code, that make the lambda cache concept not any more
efficient than not using it, at the cost of more complexity. In particular
the problems noted by :ticket:`6881` and :ticket:`6887` are made
considerably less complicated by removing this feature internally.

Fixed an issue where the :class:`_orm.Bundle` construct would not create
proper cache keys, leading to inefficient use of the query cache.  This
had some impact on the "selectinload" strategy and was identified as
part of :ticket:`6889`.

Added a Select._create_raw_select() method which essentially
performs ``__new__`` and then populates ``__dict__`` directly,
with no coercions.  This saves most of the overhead time that
the lambda caching system otherwise seeks to avoid.

Includes removal of bakedquery from
mapper->_subclass_load_via_in() which was overlooked from
the 1.4 refactor.

Fixes: #6079
Fixes: #6889
Change-Id: Ieac2d9d709b71ec4270e5c121fbac6ac870e2bb1

Change-Id: I306cfbea9920b35100e3087dcc21d7ffa6c39c55

Clarified the current purpose of the
:paramref:`_orm.relationship.bake_queries` flag, which in 1.4 is to enable
or disable "lambda caching" of statements within the "lazyload" and
"selectinload" loader strategies; this is separate from the more
foundational SQL query cache that is used for most statements.
Additionally, the lazy loader no longer uses its own cache for many-to-one
SQL queries, which was an implementation quirk that doesn't exist for any
other loader scenario. Finally, the "lru cache" warning that the lazyloader
and selectinloader strategies could emit when handling a wide array of
class/relationship combinations has been removed; based on analysis of some
end-user cases, this warning doesn't suggest any significant issue. While
setting ``bake_queries=False`` for such a relationship will remove this
cache from being used, there's no particular performance gain in this case
as using no caching vs. using a cache that needs to refresh often likely
still wins out on the caching being used side.

Fixes: #6072
Fixes: #6487
Change-Id: Ida61f09b837d3acdafa07344d7d747d7f3ab226a

Fixed issue in subquery loader strategy which prevented caching from
working correctly. This would have been seen in the logs as a "generated"
message instead of "cached" for all subqueryload SQL emitted, which by
saturating the cache with new keys would degrade overall performance; it
also would produce "LRU size alert" warnings.

In this issue we also observe that the local LRU cache for lazyloader
and selectinloader will get used for all subsequent loads as well,
which makes it more likely to hit the limit of 30.   However rather than
trying to work this out, it would be better if we removed the
loader-local LRU caches altogether once we are confident these
are working well.

Fixes: #6459
Change-Id: Id953e8f75536bb87f7e3315929cebcd8f84a5a50

Fixed regression where using :func:`_orm.selectinload` and
:func:`_orm.subqueryload` to load a two-level-deep path would lead to an
attribute error.

Fixed regression where using the :func:`_orm.noload` loader strategy in
conjunction with a "dynamic" relationship would lead to an attribute error
as the noload strategy would attempt to apply itself to the dynamic loader.

Fixes: #6419
Fixes: #6420
Change-Id: I933b208f16a9723f6ebeab7addbe118903a1f8f5

Fixed issue in the new feature of :meth:`_orm.Session.refresh` introduced
by :ticket:`1763` where eagerly loaded relationships are also refreshed,
where the ``lazy="raise"`` and ``lazy="raise_on_sql"`` loader strategies
would interfere with the :func:`_orm.immediateload` loader strategy, thus
breaking the feature for relationships that were loaded with
:func:`_orm.selectinload`, :func:`_orm.subqueryload` as well.

Also update some docs re: refresh, populate existing, etc.

Fixes: #6252
Change-Id: I5ac1430d33f1ce868426c22c7635f41f738580ce