`connection.primary_key` also return composite primary keys, so
`from_primary_key_column` may not be found even if `from_primary_key` is
presented.

```
% ARCONN=sqlite3 be ruby -w -Itest
test/cases/adapters/sqlite3/sqlite3_adapter_test.rb -n
test_copy_table_with_composite_primary_keys
Using sqlite3
Run options: -n test_copy_table_with_composite_primary_keys --seed 19041

# Running:

E

Error:
ActiveRecord::ConnectionAdapters::SQLite3AdapterTest#test_copy_table_with_composite_primary_keys:
NoMethodError: undefined method `type' for nil:NilClass
    /path/to/rails/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb:411:in
    `block in copy_table'
```

This change fixes `copy_table` to do not lose composite primary keys.

Previously, if a record was created with a custom primary key, that
table could not be migrated using sqlite. While attempting to copy the
table, the type of the primary key was ignored.

Once that was corrected, copying the indexes would fail because custom
primary keys are autoindexed by sqlite by default.

To correct that, this skips copying the index if the index name begins
with "sqlite_". This is a reserved word that indicates that the
index is an internal schema object. SQLite prohibits applications from
creating objects whose names begin with "sqlite_", so this string should
be safe to use as a check.
ref https://www.sqlite.org/fileformat2.html#intschema

This is a regression since Rails 4.2.

SQLite3 integer is stored in 1, 2, 3, 4, 6, or 8 bytes depending on the
magnitude of the value. Assuming default valid value as 4 bytes caused
that actual valid value in INTEGER storage class cannot be stored and
existing value cannot be found.

https://www.sqlite.org/datatype3.html

We should allow valid value in INTEGER storage class in SQLite3 to fix
the regression.

Fixes #22594.

Actually SQLite3 doesn't have JSON storage class (so it is stored as a
TEXT like Date and Time). But emulating JSON types is convinient for
making database agnostic migrations.

In #30510, `StatementPool` in `AbstractMysqlAdapter` was hidden in the
doc. But that class is also had in sqlite3 and postgresql adapters and
the base class is :nodoc: class.

This basically reverts 9d4f79d3

Currently `SchemaDumper` is only customizable for column options. But
3rd party connection adapters (oracle-enhanced etc) need to customizable
for table or index dumping also. To make it possible, I introduced
adapter specific `SchemaDumper` classes for that.

Because `to_sql` is public API. I introduced `to_sql_and_binds` internal
API to return SQL and binds.

A common source of bugs and code bloat within Active Record has been the
need for us to maintain the list of bind values separately from the AST
they're associated with. This makes any sort of AST manipulation
incredibly difficult, as any time we want to potentially insert or
remove an AST node, we need to traverse the entire tree to find where
the associated bind parameters are.

With this change, the bind parameters now live on the AST directly.
Active Record does not need to know or care about them until the final
AST traversal for SQL construction. Rather than returning just the SQL,
the Arel collector will now return both the SQL and the bind parameters.
At this point the connection adapter will have all the values that it
had before.

A bit of this code is janky and something I'd like to refactor later. In
particular, I don't like how we're handling associations in the
predicate builder, the special casing of `StatementCache::Substitute` in
`QueryAttribute`, or generally how we're handling bind value replacement
in the statement cache when prepared statements are disabled.

This also mostly reverts #26378, as it moved all the code into a
location that I wanted to delete.

/cc @metaskills @yahonda, this change will affect the adapters

Fixes #29766.
Fixes #29804.
Fixes #26541.
Close #28539.
Close #24769.
Close #26468.
Close #26202.

There are probably other issues/PRs that can be closed because of this
commit, but that's all I could find on the first few pages.

Abstract boolean serialization has been using 't' and 'f', with MySQL
overriding that to use 1 and 0.

This has the advantage that SQLite natively recognizes 1 and 0 as true
and false, but does not natively recognize 't' and 'f'.

This change in serialization requires a migration of stored boolean data
for SQLite databases, so it's implemented behind a configuration flag
whose default false value is deprecated. The flag itself can be
deprecated in a future version of Rails.  While loaded models will give
the correct result for boolean columns without migrating old data,
where() clauses will interact incorrectly with old data.

While working in this area, also change the abstract adapter to use
`"TRUE"` and `"FALSE"` as quoted values and `true` and `false` for
unquoted.  These are supported by PostreSQL, and MySQL remains
overriden.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

`test_middleware_caches` is sometimes failed since #29454.
The failure is due to schema statements are affected by query caching.
Bypassing query caching for schema statements to avoid the issue.

Improves the performance from O(n) to O(1).
Previously it would require 50 queries to
insert 50 fixtures. Now it takes only one query.

Disabled on sqlite which doesn't support multiple inserts.

`supports_statement_cache?` was introduced in 3.1.0.beta1 (104d0b26) for
bind parameter substitution, but it is no longer used in 3.1.0.rc1
(73ff6797). Originally it should respect `prepared_statements` rather
than `supports_statement_cache?` (fd398475).
One more thing, named `supports_statement_cache?` is pretty misreading.
We have `StatementCache` and `StatementPool`. However,
`supports_statement_cache?` doesn't mean `StatementCache`, but
`StatementPool` unlike its name.

https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/statement_cache.rb
https://github.com/rails/rails/blob/v5.1.0/activerecord/lib/active_record/connection_adapters/statement_pool.rb

* Use keyword arguments in `IndexDefinition` to ease to ignore unused
  options and to avoid to initialize incorrect empty value.
* Place it in `SchemaStatements` for consistency.
* And tiny tweaks.

`valid_type?` is used in schema dumper to determine if a type is
supported. So if `valid_type?(:foobar)` is true, it means that schema
dumper is allowed to create `t.foobar`. But it doesn't work. I think
that `valid_type?` should accept only supported types.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/lib/active_record/schema_dumper.rb#L135-L142

```ruby
  columns.each do |column|
    raise StandardError, "Unknown type '#{column.sql_type}' for column '#{column.name}'" unless @connection.valid_type?(column.type)
    next if column.name == pk
    type, colspec = @connection.column_spec(column)
    tbl.print "    t.#{type} #{column.name.inspect}"
    tbl.print ", #{format_colspec(colspec)}" if colspec.present?
    tbl.puts
  end
```

`supports_migrations?` was added at 4160b518 to determine if schema
statements (`create_table`, `drop_table`, etc) are implemented in the
adapter. But all tested databases has been supported migrations since
a4fc93c3 at least.

`valid_type?` should return true if a type exists in
`native_database_types` at least.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/lib/active_record/schema_dumper.rb#L136

Currently `change_column` cannot drop default if `null: false` is
specified at the same time. This change fixes the issue.

```ruby
  # cannot drop default
  change_column "tests", "contributor", :boolean, default: nil, null: false

  # we need the following workaround currently
  change_column "tests", "contributor", :boolean, null: false
  change_column "tests", "contributor", :boolean, default: nil
```

Closes #26582

`supports_primary_key?` was added to determine if `primary_key` is
implemented in the adapter in f0602214. But we already use `primary_key`
without `supports_primary_key?` (207f266c, 5f3cf424) and using
`supports_primary_key?` has been removed in #1318. This means that
`supports_primary_key?` is no longer used in the internal and Active
Record doesn't work without `primary_key` is implemented (all adapters
must implement `primary_key`).

Closes #27977

Follow up to #26266.

The default type of `primary_key` and `references` were changed to
`bigint` since #26266. But legacy migration and sqlite3 adapter should
keep its previous behavior.

https://www.sqlite.org/foreignkeys.html

Raise `ActiveRecord::InvalidForeignKey` when a record cannot be inserted
or updated because it references a non-existent record for SQLite3
adapter.

Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.

Some methods were added to public API in
5b14129d and they should be not part of
the public API.

Raise `ActiveRecord::NotNullViolation` when a record cannot be inserted
or updated because it would violate a not null constraint.