SQLAlchemy 2.0 upgrades (part 5)

[jdavcs]

Builds on #16852 (34 commits).
SQLAlchemy 2.0 compatibility upgrades. Ref #12541.

The main part of this PR is the _get_nested_collection_attributes method. It is dynamic and the structure of the result depends on the input. The method uses a Query object which must be replaced with a Select.

There are 2 main challenges here:

1. Unlike Query, which may return tuples of items or mapped objects, a Select always returns tuples (ref). The usual workaround is to call scalars(), which will simply return the first item from each tuple, turning [(model,), ...] into [model, ...]. However, this method, depending on input, may return tuples of items, tuples of items and mapped objects, and mapped objects. Therefore, the burden of restructuring the result has to be shifted to the caller.
2. The usage of DISTINCT requires that all columns appearing in the ORDER BY clause must also appear in the SELECT clause (see more details in commit description: c0f6b1d). We can easily add the missing columns to the select statement; however, that alters the structure of the returned values. Removing the added columns (without breaking some of the calls) is a surprisingly hard problem (the suggested approach doesn't work with a complex statement with joins and the metadata attribute which we handle differently, but which still appears in the select clause (I didn't find a way to do it using SA's public API). The alternative is to leave the added columns in the select clause - that works for the most part. The exception is the case when the columns are added dynamically and there is no way to determine how many of them will be added (depends on collection nesting): that, coupled with accessing items in the result by relative position (like here) poses the following challenge: with code like row[:-3] we intend to chop-off the last 3 elements, because we don't know how many precede them. However, with adding columns from the order by clause, we no longer know how many columns have been appended (added to the right of the list). Thus, we have a list that is dynamic "on both ends", so accessing items by relative position doesn't work. The workaround is the find_identifiers helper.
   For the rest of the cases, we use a throwaway variable *_ when destructuring the result.

Of course, this reduces the number of SA's RemovedIn20 warnings.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jdavcs]

Thanks for the review + suggestions, @mvdbeek!