Follow-up to #39147 and #39168.

By adding a new purpose-specific format, we avoid potential pitfalls
from concatenating format strings.  We also save a String allocation per
Time attribute per inspect.

The new format also includes a time zone offset for more introspective
inspection.

DATE_FORMATS can be either a format string or a lambda we don't want to attempt to concat them with a string if we are in the lambda case

In the AR test suite require_dependency does not make much sense. Just
call vanilla require/load.

Note that in the test that made explicit use of it, there are no
autoload paths, and no constants have been autoloaded. In reality, the
code ended up calling Kernel#load.

Any missing thing would be found such like #39159.

Some apps would expect that type cast is not evaluated at relation build
time consistently.

Context:

https://github.com/kamipo/rails/commit/b571c4f3f2811b5d3dc8b005707cf8c353abdf03#r31015008
https://github.com/rails/rails/pull/34303

And also this removes extra grouping on IN clause behaved as before.

SQLite3 does not recognize paths as file URIs unless the
`SQLite3::Constants::Open::URI` flag is set.  Therefore, without this
flag, a path like "file::memory:" is interpreted as a filename, causing
a "file::memory:" file to be created and used as the database.  Most
tests in `SQLite3TransactionTest` picked up this flag from
`shared_cache_flags`, but a few did not.  Because those tests were
creating a file, the path was changed in #38620 such that it no longer
pointed to an in-memory database.

This commit restores the database path as "file::memory:" and ensures
the URI flag is set whenever `in_memory_db?` is true.

Fixes #39073

This reverts commit 9817d74f, reversing
changes made to d326b029.

Just making this easier to merge our PR in. Otherwise there's tons of
conflicts and our PR is faster.

Some commits adds `**` to address kwargs warnings in Ruby 2.7, but
`save` and `save!` are originally doesn't take positional arguments, so
maintain both `*` and `**` is redundant.

https://github.com/rails/rails/commit/6d68bb5f695414b1801c1c3952ef955a5b0b6c6a
https://github.com/rails/rails/commit/09d7ce79750d08b6b9c64fd038eee285d0cbfd44
https://github.com/rails/rails/commit/51a7422c9f10cc75a3ef6bf9177324fc771d7ba4

```ruby
steve = Person.find_by(name: "Steve")
david = Author.find_by(name: "David")

relation = Essay.where(writer: steve)

# Before
relation.rewhere(writer: david).to_a # => []

# After
relation.rewhere(writer: david).to_a # => [david]
```

For now `rewhere` only works for truly column names, doesn't work for
alias attributes, nested conditions, associations.

To fix that, need to build new where clause first, and then get
attribute names from new where clause.

To change a NOT NULL constraint `reversible`.

When changing a NOT NULL constraint, we use `ActiveRecord::ConnectionAdapters::SchemaStatements#change` method that is not reversible, so `up` and `down` methods were required. Actually, we can use `change_column_null` method if only one constraint changed, but if we want to change multiple constarints with ALTER QUERY, `up` and `down` methods were required.

This is a remnant of the auto-explain feature, which was removed in
d3688e02.

Example failure: https://buildkite.com/rails/rails/builds/68661#84f8790a-fc9e-42ef-a7fb-5bd15a489de8/1002-1012

The failing `destroyed_by_association` tests create an author (a
DestroyByParentAuthor) and a book (a DestroyByParentBook) that belongs
to that author.  If the database already contains books that refer to
that author's ID from previous tests (i.e. tests that disabled
`use_transactional_tests`), then one of those books will be loaded and
destroyed instead of the intended DestroyByParentBook book.

By loading the `:books` fixtures, we ensure the database does not
contain such unexpected books.
Co-authored-by: NEugene Kenny <elkenny@gmail.com>
Co-authored-by: NRyuta Kamizono <kamipo@gmail.com>

before
```
p Knot.create
=> #<Knot id: 1, created_at: "2016-05-05 01:29:47">
```

after
```
p Knot.create
=> #<Knot id: 1, created_at: "2016-05-05 01:29:47.116928000">
```

https://buildkite.com/rails/rails/builds/68645#ebd598f6-fe4c-4273-b1a9-c78055f21874/1016-1027

Since 901d62c5, associations can only be
autosaved once: after a record has been saved, `@new_record_before_save`
will always be false. This assumes that records only transition to being
persisted once, but there are two cases where it happens multiple times:
when the transaction that saved the record is rolled back, and when the
persisted record is later duplicated.

I supposed all aggregation functions will return numeric result in
#39039, but that assumption was incorrect for `minimum` and `maximum`,
if an aggregated column is non numeric type.

I've restored type casting aggregated result for `minimum` and `maximum`.

Fixes #39110.

The type information for type casting is entirely separated to type
object, so if anyone does passing a column to `type_cast` in Rails 6,
they are likely doing something wrong. See the comment for more details:

https://github.com/rails/rails/blob/28d815b89487ce4001a3f6f0ab684e6f9c017ed0/activerecord/lib/active_record/connection_adapters/abstract/quoting.rb#L33-L42

This also deprecates passing legacy binds (an array of `[column, value]`
which is 4.2 style format) to query methods on connection. That legacy
format was kept for backward compatibility, instead of that, I've
supported casted binds format (an array of casted values), it is easier
to construct binds than existing two binds format.

We were testing the behavior of out of range ID's on where queries but
not when out of range slugs are converted to ID's.

I've found the internal `without_transaction_enrollment` callbacks which
have not been newly used over five years, when I tried to work reverting
#9068 (https://github.com/rails/rails/pull/36049#issuecomment-487318060).

I think that we will never make that callbacks public, since the
mechanism of `without_transaction_enrollment` is too implementation
specific, at least before #9068, records in a transaction had enrolled
all into the transaction.

That callbacks was introduced at #18936 to make `touch_later` #19324,
but I think that the internal callbacks is overkill to just make the
`touch_later` only, and invoking the extra callbacks also have a little
overhead even if we haven't used that.

So I think we can remove the internal callbacks for now, until we will
come up with a good use for that callbacks.

`column_types` is empty except PostgreSQL adapter, and
`attribute_types.each_key { |k| column_types.delete k }` is also empty
even if PostgreSQL adapter almost all case, so that code is quite
useless. This improves performance for `find_by_sql` to avoid that
useless loop as much as possible.

```ruby
ActiveRecord::Schema.define do
  create_table :active_storage_blobs do |t|
    t.string   :key,          null: false
    t.string   :filename,     null: false
    t.string   :content_type
    t.text     :metadata
    t.string   :service_name, null: false
    t.bigint   :byte_size,    null: false
    t.string   :checksum,     null: false
    t.datetime :created_at,   null: false

    t.index [ :key ], unique: true
  end
end

class ActiveStorageBlob < ActiveRecord::Base
end

Benchmark.ips do |x|
  x.report("find_by") { ActiveStorageBlob.find_by(id: 1) }
end
```

Before:

```
Warming up --------------------------------------
             find_by     1.256k i/100ms
Calculating -------------------------------------
             find_by     12.595k (± 3.4%) i/s -     64.056k in   5.091599s
```

After:

```
Warming up --------------------------------------
             find_by     1.341k i/100ms
Calculating -------------------------------------
             find_by     13.170k (± 3.5%) i/s -     67.050k in   5.097439s
```

To avoid column types loop for PostgreSQL adapter, this skips returning
additional column types if a column has already been type casted by pg
decoders. Fortunately this fixes #36186 partly for common types.

https://buildkite.com/rails/rails/builds/68559#2decc846-c6b5-46f7-a805-426a8063d36c/1016-1027

Relying on the `Arel::Table.engine` is convenient if an app have only a
single kind of database, but if not so, the global state is not always
the same with the current connection.

`allowed_index_name_length` was used for internal temporary operations
in SQLite3, since index name in SQLite3 must be globally unique and
SQLite3 doesn't have ALTER TABLE feature (so it is emulated by creating
temporary table with prefix).

`allowed_index_name_length` was to reserve the margin for the prefix,
but actually SQLite3 doesn't have a limitation for identifier name
length, so the margin has removed at 36901e6e.

Now `allowed_index_name_length` is no longer relied on by any adapter,
so I'd like to remove the internal specific method which is no longer
used.

This is a smaller alternative of performance improvement, without
refactoring type casting mechanism #39009.

This is relatively a smaller change (but about 40% faster than before),
so I think this could be easier reviewed without discuss about
refactoring type casting mechanism.

This just makes `attribute.in(values)` less allocation from an array of
casted nodes to one casted array node.

```ruby
ids = (1..1000).each.map do |n|
  Post.create!.id
end

Benchmark.ips do |x|
  x.report("where with ids") do
    Post.where(id: ids).to_a
  end

  x.report("where with sanitize") do
    Post.where(ActiveRecord::Base.sanitize_sql(["id IN (?)", ids])).to_a
  end

  x.compare!
end
```

Before:

```
Warming up --------------------------------------
      where with ids     7.000  i/100ms
 where with sanitize    13.000  i/100ms

Calculating -------------------------------------
      where with ids     70.661  (± 5.7%) i/s -    357.000  in   5.072771s
 where with sanitize    130.993  (± 7.6%) i/s -    663.000  in   5.096085s

Comparison:
 where with sanitize:      131.0 i/s
      where with ids:       70.7 i/s - 1.85x  slower
```

After:

```
Warming up --------------------------------------
      where with ids    10.000  i/100ms
 where with sanitize    13.000  i/100ms

Calculating -------------------------------------
      where with ids     98.174  (± 7.1%) i/s -    490.000  in   5.012851s
 where with sanitize    132.289  (± 8.3%) i/s -    663.000  in   5.052728s

Comparison:
 where with sanitize:      132.3 i/s
      where with ids:       98.2 i/s - 1.35x  slower
```

Define `value_for_database` and `value_before_type_cast` methods, and
use those.

`in_clause_length` was added at c5a284f8 to address to Oracle IN clause
length limitation.

Now `in_clause_length` is entirely integrated in Arel visitor since
#35838 and #36074.

Since Oracle visitors are the only code that rely on `in_clause_length`.
so I'd like to remove that from Rails code base, like has removed Oracle
visitors (#38946).

Before this, 1000 `Or` nodes will raise "stack level too deep" due to
visiting too deep Arel ast.

This makes more concise Arel `Or` ast and `Or` visitor non recursive if
`Or` nodes are adjoined, as a result, "stack level too deep" is no
longer raised.

```ruby
class Post < ActiveRecord::Base
end

posts = (0..500).map { |i| Post.where(id: i) }

Benchmark.ips do |x|
  x.report("inject scopes") { posts.inject(&:or).to_sql }
end
```

Before:

```
Warming up --------------------------------------
      where with ids     9.000  i/100ms
Calculating -------------------------------------
      where with ids     96.126  (± 2.1%) i/s -    486.000  in   5.058960s
```

After:

```
Warming up --------------------------------------
       inject scopes    10.000  i/100ms
Calculating -------------------------------------
       inject scopes    101.714  (± 2.9%) i/s -    510.000  in   5.018880s
```

Fixes #39032.

Skip test cases for upsert_all on relation if database adapter doesn't support update on duplicate records

If only one Arel node exist, wrapping a node by `And` node is obviously
redundant, make concise Arel ast will improve performance for visiting
the ast (about 20% faster for complex ast case).

```ruby
class Post < ActiveRecord::Base
end

posts = (0..500).map { |i| Post.where(id: i) }

Benchmark.ips do |x|
  x.report("inject scopes") { posts.inject { |res, scope| res.or(scope) }.to_sql }
end
```

Before:

```
Warming up --------------------------------------
      where with ids     8.000  i/100ms
Calculating -------------------------------------
      where with ids     80.416  (± 2.5%) i/s -    408.000  in   5.078118s
```

After:

```
Warming up --------------------------------------
      where with ids     9.000  i/100ms
Calculating -------------------------------------
      where with ids     96.126  (± 2.1%) i/s -    486.000  in   5.058960s
```

Currently, `count` and `average` always returns numeric value, but
`sum`, `maximum`, and `minimum` not always return numeric value if
aggregated on custom attribute type.

I think that inconsistent behavior is surprising:

```ruby
# All adapters except postgresql adapter are affected
# by custom type casting.

Book.group(:status).sum(:status)
# => { "proposed" => "proposed", "published" => nil }
```

That is caused by fallback looking up cast type to `type_for(column)`.
Now all supported adapters can return numeric value without that
fallback, so I think we can remove that, it will also fix aggregate
functions to return numeric value consistently.

This allows to work `author.books.insert_all` as expected.
Co-authored-by: NJosef Šimánek <josef.simanek@gmail.com>

mysql2 gem have type casting mechanism from raw payload to Ruby
primitive object.

There is no worth to keep those unused aliases and tests which are
private API.