- Test newest Ruby + next Rails (main, 3.4)
- Text next Ruby + newest Rails (8.0, 3.3)
- Test next Ruby + next Rails (main, 3.4)

All of these can fail, but it's useful to know.

    The following actions use a deprecated Node.js version and will be forced to
    run on node20: actions/cache@v3. For more info:
    https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

It's time for everyone's favorite game: bump the versions! Ruby 3.4 is
out, and Rails 8 has been shipped for some time. We try to keep our CI
suite testing currently-supported versions of each, but we don't want a
giant matrix that requires many customizations to run successfully
either.

As a result, this commit:

* Adds testing our full matrix with Ruby 3.4
* Drops testing with Ruby 3.1
* Drops testing with Rails 7.1

I think this is a good balance of testing the latest versions of Ruby
and Rails while maintaining some backward compatibility in a manner that
doesn't require a degree in YAML to understand.

This is Postgres-specific code, and it shouldn't have been here.

scenic-views#416 (comment)

When performing the sort logic, we were treating results from postgres
like they were already Scenic view objects, which they were not. This
change makes sure that we are working with the correct objects.

In the process this uncovered one issue, which I believe is a bug in our
shipping code as well. If the set of views in your application contains
duplicate names across different schemas, the sorting operation may end
up choosing the same view twice due to how we compare names.

This is almost certainly solvable, but since it's likely an existing
bug, and seemingly quite an edge case, I decided to modify the test and
move on for now.

This implementation will still error if you ask for a concurrent refresh
of a non-populated view if your database does not support concurrent
refreshes. I'm happy with this because the user has asked for a thing
that we know cannot succeed, even under the right circumstances, and we
should tell them that., and we should tell them that.

Co-authored-by: Derek Prior <[email protected]>
Co-authored-by: Caleb Hearth <[email protected]>

This adds a `side_by_side` kwarg to the `update_materialized_view`
method, which builds the new view alongside the old one and then
atomically swaps them to reduce downtime at the cost of increasing disk
usage. It is plumbed through to migrations as a hash value for the
`materialized` kwarg of `update_view`.

The initial implementation of side_by_side materialized view creation
worked but had a couple of issues that needed to be resolved and I
wanted to refactor the code for better maintainability.

* We had postgres-specific things in the `Scenic::Index` class, which is
  not part of the adapter API. The code was refactored to not rely on
  adding the schema name to this object.
* Index migration is different from index reapplication, and it felt
  like we were reusing `IndexReapplication` just to get access to the
  `SAVEPOINT` functionality in that class. I extracted `IndexCreation`
  which is now used by `IndexReapplication` and our new class,
  `IndexMigration`.
* Side-by-side logic was moved to a class of its own, `SideBySide`, for
  encapsulation purposes.
* Instead of conditionally hashing the view name in the case where the
  temporary name overflows the postgres identifier limit, we now always
  hash the temporary object names. This just keeps the code simpler and
  observed behavior from the outside identical no matter identifier
  length. This behavior is tested in the new `TemporaryName` class.
* Removed `rename_materialized_view` from the public API on the adapter,
  as I'd like to make sure that's something we want separate from this
  before we do something like that.
* Added `connection` to the public adapter UI for ease of use from our
  helper objects. Documented as internal use only.
* Require a transaction in order to use `side_by_side`. This prevents
  leaving the user in a weird state that would be difficult to recover
  from.
* Added `--side-by-side` (and `--side_by_side`) support to the
  `scenic:view` generator. Also added `--no-data` as an alias for the
  existing `--no_data` while I was at it.
* I added a number of tests for new and previously existing code
  throughout, including an acceptance level test for `side_by_side`. Our
  test coverage should be much improved.
* Updated README with information on `side_by_side`.

Here's a sample of the output from running a `side_by_side` update:

```
== 20250102191533 UpdateSearchesToVersion3: migrating =========================
-- update_view(:searches, {version: 3, revert_to_version: 2, materialized: {side_by_side: true}})
   -> temporary materialized view _scenic_sbs_8a03f467c615b126f59617cc510d2abd41296834 has been created
   -> indexes on 'searches' have been renamed to avoid collisions
   -> index 'index_searches_on_content' on '_scenic_sbs_8a03f467c615b126f59617cc510d2abd41296834' has been created
   -> index 'index_searches_on_user_id' on '_scenic_sbs_8a03f467c615b126f59617cc510d2abd41296834' has been created
   -> materialized view searches has been dropped
   -> temporary materialized view _scenic_sbs_8a03f467c615b126f59617cc510d2abd41296834 has been renamed to searches
   -> 0.0299s
== 20250102191533 UpdateSearchesToVersion3: migrated (0.0300s) ================
```