This reverts commit 43ccebc1.

This is not fixing the configuration problem since we are assigning to
the ActiveRecord::Base not the configuration. See #24303.

These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.

While the option on `ActiveRecord::Base` is always around, we need to
explicitly set it on the config object. Otherwise the recommended
configuration change results in an error.

Fixes #22839

When `rails console` or `rails server` are used along with a logger set to output to `STDOUT` then the contents will show up twice. This happens because the logger is extended with `ActiveSupportLogger.broadcast` with a destination of STDOUT even if it is already outputting to `STDOUT`.

Previously PR #22592 attempted to fix this issue, but it ended up causing NoMethodErrors. A better approach than relying on adding a method and flow control is to inspect the log destination directly. For this `ActiveSupport::Logger.logger_outputs_to?` was introduced

```ruby
logger = Logger.new(STDOUT)
ActiveSupport::Logger.logger_outputs_to?(logger, STDOUT)
# => true
```

To accomplish this we must look inside of an instance variable of standard lib's Logger `@logdev`. There is a related Ruby proposal to expose this method in a standard way: https://bugs.ruby-lang.org/issues/11955

Still more to do. Please assist!

change AR clear order in ActionDisplatch::Reloader hook

The `db:schema:cache:dump` rake task dumps the database schema structure
to `db/schema_cache.dump`. If this file is present, the schema details
are loaded into the currently checked out connection by a railtie while
Rails is booting, to avoid having to query the database for its schema.

The schema cache dump is only applied to the initial connection used to
boot the application though; other connections from the same pool are
created with an empty schema cache, and still have to load the structure
of each table directly from the database.

With this change, a copy of the schema cache is associated with the
connection pool and applied to connections as they are created.

When set to an integer, a warning will be logged whenever a result set
larger than the specified size is returned by a query. Fixes #16463

The warning is outputed a module which is prepended in an initializer,
so there will be no performance impact if
`config.active_record.warn_on_records_fetched_greater_than` is not set.

This introduces undesirable `Rails.logger` formatters (such as the syslog
formatter) onto a `Logger.new(STDERR)` for the console. The production
logger may be going elsewhere than standard io, so we can't presume to
reuse its formatter.

With syslog, this causes missing newlines in the console, so irb prompts
start at the end of the last log message.

We can work to expose the console formatter in another way to address
the original issue.

This reverts commit 026ce5dd, reversing
changes made to 6f0a69c5.

[Rafael Mendonça França & Yves Senn]

This require caused the `active_record.set_configs` initializer to
run immediately, before `config/initializers`. This means that setting any
configuration on `Rails.application.config.active_record` inside of
an initializer had no effects when rails was loaded through `rake`.

Introduced by #6518

/cc @rafaelfranca

* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
  message in-place.
* Preserve the original backtrace of other errors by using `raise`
  rather than raising again with `raise error`.

References 0ec45cd1

Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored.

There are many ways that active record initiates a connection today:

- Stand Alone (without rails)
  - `rake db:<tasks>`
  - ActiveRecord.establish_connection
 
- With Rails
  - `rake db:<tasks>`
  - `rails <server> | <console>`
  - `rails dbconsole`


We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used.

Here is my prosed matrix of how this behavior should work:

```
No database.yml
No DATABASE_URL
=> Error
```

```
database.yml present
No DATABASE_URL
=> Use database.yml configuration
```

```
No database.yml
DATABASE_URL present
=> use DATABASE_URL configuration
```

```
database.yml present
DATABASE_URL present
=> Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url`
   sub key "wins". If other paramaters `adapter` or `database` are specified in YAML,
   they are discarded as the `url` sub key "wins".
```

### Implementation

Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`.

To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.

* Move check from generated helper to test_help.rb, so that all
  applications can benefit
* Rather than just raising when the test schema has pending migrations,
  try to load in the schema and only raise if there are pending
  migrations afterwards
* Opt out of the check by setting
  config.active_record.maintain_test_schema = false
* Deprecate db:test:* tasks. The test helper is now fully responsible
  for maintaining the test schema, so we don't need rake tasks for this.
  This is also a speed improvement since we're no longer reloading the
  test database on every call to "rake test".

Warning:

  ~/projects/rails/activerecord/lib/active_record/railtie.rb:140: warning: method redefined; discarding old extend_message
  ~/projects/rails/activerecord/lib/active_record/errors.rb:104: warning: previous definition of extend_message was here

This commit also cleans up the rake tasks that were checking
for DATABASE_URL in different places.

In fact, it would be nice to deprecate DATABASE_URL usage in the long
term, considering the direction we are moving of allowing those in .yml
files.

Currently if you attempt to use a database that does not exist  you get an error:

```
PG::ConnectionBad FATAL:  database "db_error" does not exist
```

The solution is easy, create and migrate your database however new developers may not know these commands by memory. Instead of requiring the developer to search for a solution, tell them how to fix the problem in the error message:

```
ActiveRecord::NoDatabase: FATAL:  database "db_error" does not exist
Run `$ bin/rake db:create db:migrate` to create your database
```

Active Record should not know about `rake db:migrate` so this additional information needs to come from the railtie. Potential alternative implementation suggestions are welcome.

Those vars can be used in tasks, which not call load_config.

In commit d1d7c86d I moved setting migrations paths into activerecord's
railtie to remove Rails dependency on databases.rake. However, it
introduced a regression, ENGINE_PATH was not available at the moment, so
engine's migrations where not added properly to paths. Fix was added
at 97a4a771, but it changes a way things work from using ENGINE_PATH to
APP_RAKEFILE. Additionally, the config runs when the code loads, while
previously it ran in the db:load_config rake task

In order to make it more in pair with original version this commit
changes the config to run only on load_config task. This code uses the
fact that defining a task in rake does not overwrite, but only appends.

It also allows to get back to checking for ENGINE_PATH

Broken by d1d7c86d

This will allow to set fixtures path in global config easier, it should
be not needed to use FIXTURES_PATH every time user wants to load
fixtures.

We discussed that the auto explain feature is rarely used.
This PR removes only the automatic explain. You can still display
the explain output for any given relation using `ActiveRecord::Relation#explain`.

As a side-effect this should also fix the connection problem during
asset compilation (#9385). The auto explain initializer in the `ActiveRecord::Railtie`
forced a connection.

make connection_url_to_hash a class method

This als prevents loading database.yml if it doesn't exist
but DATABASE_URL does

Rather than just raising a NoMethodError when copying the config, this
commit adds a warning message until either the rails-observers gem is
installed or the relevant config options are removed.