Treat ActiveRecord::Base and ApplicationRecord as "primary"

[eileencodes]

When someone has a multi-db application their ApplicationRecord will
look like:

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to database: { writing: :primary, reading: :replica }
end

This will cause us to open 2 connections to ActiveRecord::Base's
database when we actually only want 1. This is because Rails sees
ApplicationRecord and thinks it's a new connection, not the existing
ActiveRecord::Base connection because the
connection_specification_name is different.

This PR changes ApplicationRecord classes to consider themselves the
same as the "primary" connection.

Fixes #36382

Note: this needs a backport to 6-0-stable

cc/ @tenderlove @jhawthorn @rafaelfranca @matthewd @morgoth

[tenderlove]

Does this mean that AR::Base must have the same connection configuration as ApplicationRecord?

[eileencodes]

I'm not sure why you'd set up one that's different. ApplicationRecord already assumes that it's ActiveRecord::Base, it's just that we never call establish_connection from it before. Do you know of a use case where you'd want a different connection configuration for AR::Base and ApplicationRecord?

[eileencodes]

To followup on this a bit Aaron and I talked on Slack about "why can't Rails just automatically connect on boot to the replica instead of manually connecting to the replica in ApplicationRecord?"

There are a few reasons why:

1. Since we don't associate replicas to their primaries Rails doesn't actually know which one of the replica definitions is for the primary database, aka one that ActiveRecord::Base connects to. Eventually I'd like to change the configurations to be able to handle this but we had a ton of work to do for Rails 6 and that just wasn't going to make it in.
2. On boot Rails calls establish_connection with no arguments. In current Rails 6.0 and master this will establish a connection to the primary database in the environment you're in (ie development primary). We could theoretically loop through the configurations and look up a replica for the development primary database but that replica would have to have a specific name that cannot change (primary_replica or something like that). I'm not sure at this point in the 6.0 release it would be a good idea to force users to use a specific name for the replica.
3. To be totally selfish this wouldn't work for GitHub without us changing our replica keys because ours is called something other than primary_replica. This isn't "hard", but isn't convenient either.

As for the concerns regarding "what if someone is on a legacy app and they don't have an ApplicationRecord?"

• This is solved by Rails requiring as of 5.0 that you must add an ApplicationRecord

And lastly "what if someone is connecting to one database for ActiveRecord::Base and another for ApplicationRecord?"

• Normally I don't like to use this argument but I'd say that you're doing it wrong. ApplicationRecord was always meant to be tied to ActiveRecord::Base and each connection should have their own abstract class to deal with their connection.

[eileencodes]

I changed this because technically in a new app this is what Post would inherit from and checking defined? loaded ApplicationRecord in this test. In master if I change this line the same thing happens so I think that this more accurately demonstrates what a real app would load/unload.