Rails 7.1 config and deprecation -- step 1

[jrochkind]

While #2431 upgraded to Rails 7.1, and was green in CI -- it did not update any configuration defaults to match Rails 7.1 yet, and still produced some Rails 7.1 deprecation warnings.

This PR is separated for ease of review, but it should be merged and deployed simultaneous with #2431.

It eliminates any deprecation warnings when run under Rails 7.1, and also updates much configuration to match Rails 7.1 defaults.

How we found what to update

First we checked railsdiff.com, to reivew how a newly generated app under Rails 7.1 might differ from Rails 7.0. We manually reviewed, and updated some local files to match. See for instance https://railsdiff.org/7.0.8/7.1.2

THEN we used the new_framework_defaults_7_1.rb file generated by Rails to opt into new defaults one by one, and see which ones if any broke our tests. https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#configure-framework-defaults. You can see this file in this PR.

We did NOT opt into any defaults that would keep our app from going back to 7.0 -- mainly ones that change serialization formats to ones that are not backwards compat and could not be readalbe by a 7.0 app.

At some LATER point, when we've been running 7.1 several weeks and know we won't need to go back -- we'll have another PR to fully take all 7.1 defaults, with load_defaults in application.rb instead of the new_framework_defaults... file.

Actual problem with run_after_transaction_callbacks_in_order_defined

So... ONE piece of config, run_after_transaction_callbacks_in_order_defined, actually did cause our tests to fail -- and it was catching real problem.

To make things more confusing -- at FIRST we didn't catch this, becuase it turned out enabling this in new_framework_defaults_7_1.rb didn't actually enable it in time to effect our Asset class. I noticed the problem when trying out the future branc that would have load_defaults 7.1 -- THAT one triggered the problem.

I realized that for reasons I won't go into here, we load our Asset classes during initialization, so we had to opt into this config before the initializer -- in application.rb. I did so to demonstrate the problem, then set about solving it.

It turned out to be pretty confusing -- we had some after_commit hooks in Asset, that need to run before shrine promotion, so they can look at file_data_previously_changed and see the delta that caused the shrine promotion, rather than the delta of the promotion.

Rails 7.1 defaults changed the order of after_commit hooks so they were broken... and Rails 7.1 didn't actually give us any tools to alter this! I was pretty stymied, but figured out using other Rails public API (I think!), I could easily implement a method that did let us insert after_commit hooks where we needed. That is implemented in kithe at sciencehistory/kithe#178

Then this PR right here upgrades to a version of kithe with the new function, and uses the new function to register the after_commit hooks so they will run before shrine promotion, and have access to the right previously changed deltas.

Phew!

[jrochkind]

Wow, weird this is failing in CI -- it passed for me locally!

Based on the error, may have something to do with the app setup step, setting up the database etc, that we don't normally do in development... will have to spend more time with this.

[jrochkind]

in CI change db:create to db:prepare

Previously on CI, somehow our DB schema was getting loaded... but after moving to Rails 7.1 it wasn't and was causing an error. Not sure what was going on before, but in CI setup script changing 'db:create' to 'db:prepare` tells rails to create the DB and load the schema, and fixes our build