Using `config.load_defaults` applies a large number of recommended config options, but some of them introduce breaking changes. By selectively disabling the ones that don't work nicely with OFN we can still get the benefits of all the other enabled options.
These options currently don't play nicely with OFN, and break the CI build in various places.
This:
```
DEPRECATION WARNING: Initialization autoloaded the constant User.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload User, for example,
the expected changes won't be reflected in that stale Class object.
This autoloaded constant has been unloaded.
In order to autoload safely at boot time, please wrap your code in a reloader
callback this way:
Rails.application.reloader.to_prepare do
# Autoload classes and modules needed at boot time here.
end
That block runs when the application boots, and every time there is a reload.
For historical reasons, it may run twice, so it has to be idempotent.
Check the "Autoloading and Reloading Constants" guide to learn more about how
Rails autoloads and reloads.
```
This checks if the current request has been submitted using the old session key (_session_id) and transparently migrates the session id to a new session cookie with the new settings and the new key (_ofn_session_id).
We should migrate to ActiveStorage soon, but we're not using it yet. ActionText is cool but we also don't currently use it. ActionMailbox is not something we need at all.
Rails has changed the way helpers are loaded. It's a bit weird. It was throwing lots of errors, and recommended using this setting, but now requires that all helpers are loaded explicitly. I'm not sure about this.
Rails 5.2 has changed the way initializers are called during certain rake tasks including `db:create`. Initializers that were previously not loaded are now loaded (basically the whole app is loaded). This means any calls to #table_exists? that appear in the app will throw fatal errors as the database doesn't exist yet during that task, but those calls are made before `db:create` has even started, which means the database can't be created.
There are also a few other places in Spree code where #table_exists? is called, and they already call #connected? first to guard against this issue.
