Extract AP Page and Action caching from Rails

According to the rationale atrails#7833 (comment), we should recommend new users to follow DHH's approach outlined athttp://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works.This is the first step, and perhaps in the future we can write some specific recommendations out.

Instrumentation hooks for `write_page.action_controller` and`expire_page.action_controller` seem to be removedinrails#7833.So, subscribers for them are no longer necessary.

…s url or fallbackrefactor: add port numberrefactor: add default fallback if default options has no hosttest(rails console): session host is correctrefactor: set default url in correct filerefactor: remove code that is not neededRemove unused instrumentation hooks from action_controllerInstrumentation hooks for `write_page.action_controller` and`expire_page.action_controller` seem to be removedinrails#7833.So, subscribers for them are no longer necessary.Fix new method name in DatabaseConfig#config deprecation messageReplace "ActionText" with "Action Text" [ci skip]http://guides.rubyonrails.org/api_documentation_guidelines.html#wordingRemove unnecessary if in ExtendedDeterministicUniquenessValidatorSpecify ORDER BY enumsortorder for postgres enumsCo-authored-by: Daniel Colson <danieljamescolson@gmail.com>Restore set_autoload_path triggering before bootstrapFixesrails#43205.Automatically infer inverse_of with scopesBackground---I recently noticed we had a number of associations in GitHub that wouldbenefit from having `inverse_of` set, and so I began adding them. Iended up adding them to virtually every association with a scope, atwhich point I wondered whether Rails might be able to automatically findthese inverses for us.For GitHub, the changes in this commit end up automatically adding`inverse_of` to 171 of associations that were missing it.My understanding is that we do not automatically detect `inverse_of` forassociations with scopes because the scopes could exclude the records weare trying to inverse from. But I think that should only matter if thereis a scope on the inverse side, not on the association itself.For example:Scope on has_many----```rbclass Post < ActiveRecord::Base  has_many :comments, -> { visible }endclass Comment < ActiveRecord::Base  belongs_to :post  scope :visible, -> { where(visible: true) }  scope :hidden, -> { where(visible: false) }endpost = Post.create!comment = post.comments.hidden.create!assert comment.post```This code leaves `post.comments` in sort of a weird state, since itincludes a comment that the association would filter out. But that'strue regardless of the changes in this commit.Regardless of whether the comments association has an inverse,`comment.post` will return the post. The difference is that when`inverse_of` is set we use the existing post we have in memory, ratherthan loading it again. If there is a downside to having the `inverse_of`automatically set here I'm not seeing it.Scope on belongs_to----```rbclass Post < ActiveRecord::Base  has_many :comments  scope :visible, -> { where(visible: true) }  scope :hidden, -> { where(visible: false) }endclass Comment < ActiveRecord::Base  belongs_to :post, -> { visible }endpost = Post.hidden.create!comment = post.comments.create!assert_nil comment.post```This example is a different story. We don't want to automatically inferthe inverse here because that would change the behavior of`comment.post`. It should return `nil`, since it's scoped to visibleposts while this one is hidden.This behavior was not well tested, so this commit adds a test toensure we haven't changed it.Changes---This commit changes `can_find_inverse_of_automatically` to allow us toautomatically detect `inverse_of` when there is a scope on theassociation, but not when there is a scope on the potential inverseassociation. (`can_find_inverse_of_automatically` gets called first withthe association's reflection, then if it returns true we attempt to findthe inverse reflection, and finally we call the method again with theinverse reflection to ensure we can really use it.)Since this is a breaking change—specifically in places where code mayhave relied on a missing `inverse_of` causing fresh copies of a recordto be loaded—we've placed it behind the `automatic_scope_inversing` flag(whose name was inspired by `has_many_inversing`). It is set to true fornew applications via framework defaults.Testing---In addition to the inverse association tests, this commit also adds somecases to a few tests related to preloading. They are basicallyduplicates of existing tests, but with lower query counts.Testing this change with GitHub, the bulk of the failing tests wererelated to lower query counts. There were additionally 3 places (2 intests and one in application code) where we relied on missing`inverse_of` causing fresh copies of a record to be loaded.There's still one Rails test that wouldn't pass if we ran the wholesuite with `automatic_scope_inversing = true`. It's related to`TaggedPost`, which changes the polymorphic type from the base class`Post` to the subclass `TaggedPost`.```rbclass TaggedPost < Post  has_many :taggings, -> { rewhere(taggable_type: "TaggedPost") }, as: :taggableend```Setting the inverse doesn't work because it ends up changing the typeback to `Post`, something like this:```rbpost = TaggedPost.newtagging = post.taggings.newputs tagging.taggable_type=> TaggedPosttagging.taggable = postputs tagging.taggable_type=> Post```I think this is an acceptable change, given that it's a fairly specificscenario, and is sort of at odds with the way polymorphic associationsare meant to work (they are meant to contain the base class, not thesubclass). If someone is relying on this specific behavior they canstill either keep `automatic_scope_inversing` set to false, or they canadd `inverse_of: false` to the association.I haven't found any other cases where having the `inverse_of` wouldcause problems like this.Co-authored-by: Chris Bloom <chrisbloom7@gmail.com>Remove message from ActiveRecord::Rollback exampleDo not suggest that raising `ActiveRecord::Rollback` exception should have a message.There's no point of adding a message to `ActiveRecord::Rollback` exception because it will be rescued by transaction block and the message will be lost.Use queue_classic branch which works on psql 14This fixes the failing CI for ActiveJob.This uses my fork, we can switch back when the following PR is merged:QueueClassic/queue_classic#334Add ability to lazily load the schema cache on connectionThis adds a configuration option and code to enable lazy loading of theschema cache on the connection. If`config.active_record.lazily_load_schema_cache` is set to `true` thenthe Railtie will be completely skipped and the schema cache will beloaded when the connection is established rather than on boot.We use this method at GitHub currently in our custom adapter. It enablesus to load schema caches lazily. It also is a solution for schema cacheswith multiple databases. The Railtie doesn't know about the otherconnections _before_ boot so it can only load the cache for`ActiveRecord::Base.connection`. Since this loads the cache on`establish_connection` Rails doesn't need to know anything special aboutthe connections.Applications can continue dumping the cache like normal, the change isonly to how the schema cache is loaded. To use the lazy loaded schemacache a `schema_cache_path` must be set in the database configuration,otherwise `db/schema_cache.yml` will be used.Followup questions:1) Should we deprecate the Railtie?2) The Railtie does more work than we're doing here because it checksthe version against the current version. I'm not sure we really wantto do this in Rails - we don't do it in ours at GitHub.Replace ableist languageThe word "Crazy" has long been associated with mental illness. Whilethere may be other dictionary definitions, it's difficult for some of usto separate the word from the stigmatization, gaslighting, and bullyingthat often comes along with it.This commit replaces instances of the word with various alternatives. Ifind most of these more focused and descriptive than what we had before.Remove "matches?" from AS::N subscriber classesThis was not being used anymoreMove AllMessages behaviour into MatcherThis avoids needing to delegate all methods to the actual subscriberclass and we can deal just with the message name matching behaviour.Don't require role when passing shard to connected_toOriginally we required `role` when switching `shard`'s because I felt itmade it less confusing. However now that we're exploring some moremulti-tenancy work I agree we need to move this condition. Otherwise ifyou're using one middleware to switch roles and another to switchshards, you may be forced to pass the role around in places you're onlyconcerned with shard. This also simplifies the call for applicationsthat don't use roles and only have writer shards.chore: squash commitsrefactor: include url helpersReplace more ableist languageAlong the same lines asccb3cb5, this commit removes unnecessaryreferences to mental health.As in that commit, I think many of these are more descriptive than whatwe had before.The commit changes only tests and documentation.Remove refenrence to destroy_all_in_batches configThis feature was reverted.refactor: fix testfix(rails console): change session host to  application default url options host