fail to emit an UPDATE in the case where the attribute were set to
None and not previously loaded.
fixes #3599

add sane_multi_rowcount requirement, as pg8000 doesn't do "multi" row count.

sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing

to get all flake8 passing

of work such that loading for related many-to-one objects is slightly
more aggressive, in the case of a graph of self-referential objects
that are to be deleted; the load of related objects is to help
determine the correct order for deletion if passive_deletes is
not set.
- revert the changes to test_delete_unloaded_m2o, these deletes do in fact
need to occur in the order of the two child objects first.

implicitly initialized to None via first access; this action,
which has always resulted in a population of the attribute,
now emits an attribute event just like any other attribute set
operation and generates the same kind of history as one.  Additionally,
many mapper internal operations will no longer implicitly generate
these "None" values when various never-set attributes are checked.
These are subtle behavioral fixes to attribute mechanics which provide
a better solution to the problem of :ticket:`3060`, which also
involves recognition of attributes explicitly set to ``None``
vs. attributes that were never set.
fixes #3061

scenario, where an INSERT/DELETE can be turned into an UPDATE.
In this situation, a many-to-one relationship set to None, or
in some cases a scalar attribute set to None, may not be detected
as a net change in value, and therefore the UPDATE would not reset
what was on the previous row.   This is due to some as-yet
unresovled side effects of the way attribute history works in terms
of implicitly assuming None isn't really a "change" for a previously
un-set attribute.  See also :ticket:`3061`. fixes #3060

would fail to delete the association row and raise an error
if the scalar attribute were set to None.  Also in 0.7.11.
[ticket:2710]