Allow quoted identifier string as safe SQL string

Since quoted `Infinity` and `NaN` are valid data for PostgreSQL.

An empty string is an invalid value in Ruby's range class.
So need to handle `Float::INFINITY` as it is and cast it in
`encode_range`.

Fixes #31612

PostgreSQL 9.1+ introduced range types, and Rails added support for
using this datatype in ActiveRecord. However, the serialization of
`PostgreSQL::OID::Range` was incomplete, because it did not properly
quote the bounds that make up the range. A clear example of this is a
`tsrange`.

Normally, ActiveRecord quotes Date/Time objects to include the
milliseconds. However, the way `PostgreSQL::OID::Range` serialized its
bounds, the milliseconds were dropped. This meant that the value was
incomplete and not equal to the submitted value.

An example of normal timestamps vs. a `tsrange`. Note how the bounds
for the range do not include their milliseconds (they were present in
the ruby Range):

    UPDATE "iterations" SET "updated_at" = $1, "range" = $2 WHERE
    "iterations"."id" = $3
    [["updated_at", "2017-09-23 17:07:01.304864"],
    ["range", "[2017-09-23 00:00:00 UTC,2017-09-23 23:59:59 UTC]"],
    ["id", 1234]]

`PostgreSQL::OID::Range` serialized the range by interpolating a
string for the range, which works for most cases, but does not work
for timestamps:

    def serialize(value)
      if value.is_a?(::Range)
        from = type_cast_single_for_database(value.begin)
        to = type_cast_single_for_database(value.end)
        "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}"
      else
        super
      end
    end

    (byebug) from = type_cast_single_for_database(value.begin)
    2010-01-01 13:30:00 UTC

    (byebug) to = type_cast_single_for_database(value.end)
    2011-02-02 19:30:00 UTC

    (byebug) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}"
    "[2010-01-01 13:30:00 UTC,2011-02-02 19:30:00 UTC)"

@sgrif (the original implementer for Postgres Range support) provided
some feedback about where the quoting should occur:

  Yeah, quoting at all is definitely wrong here. I'm not sure what I
  was thinking in 02579b56, but what this is doing is definitely in the
  wrong place. It should probably just be returning a range of
  subtype.serialize(value.begin) and subtype.serialize(value.end), and
  letting the adapter handle the rest.

`Postgres::OID::Range` now returns a `Range` object, and
`ActiveRecord::ConnectionAdapters::PostgreSQL::Quoting` can now encode
and quote a `Range`:

    def encode_range(range)
      "[#{type_cast(range.first)},#{type_cast(range.last)}#{range.exclude_end? ? ')' : ']'}"
    end

    ...

    encode_range(range)
    #=> "['2010-01-01 13:30:00.670277','2011-02-02 19:30:00.745125')"

This commit includes tests to make sure the milliseconds are
preserved in `tsrange` and `tstzrange` columns

Fixes #30539.

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.

`quote_default_expression` can be passed nil value when `null: true` and
`default: nil`. This addressed in that case.

Fixes #29222.

The old top level classes PGconn, PGresult and PGError were deprecated
since pg-0.13.0: https://github.com/ged/ruby-pg/blob/master/History.rdoc#v0130-2012-02-09-michael-granger-gedfaeriemudorg

In f1a0fa9e we moved backend specific timestamp behavior out of the type
and into the adapter. This was in line with our general attempt to
reduce the number of adapter specific type subclasses. However, on PG,
the array type performs all serialization, including database encoding
in its serialize method.

This means that we have converted the value into a string before
reaching the database, so no adapter specific logic can be applied (and
this also means that timestamp arrays were using the default `.to_s`
method on the given object, which likely meant timestamps were being
ignored in certain cases as well)

Ultimately I want to do a more in depth refactoring which separates
database serializer objects from the active model type objects, to give
us a less awkward API for introducing the attributes API onto Active
Model.

However, in the short term, we follow the solution we've applied
elsewhere for this. Move behavior off of the type and into the adapter,
and use a data object to allow the type to communicate information up
the stack.

Fixes #27514.

Each databases have different binary representation. Therefore all
adapters overrides `_quote` for quoting binary.
Extract `quoted_binary` for quoting binary and use it rather than
override `_quote`.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Caching a mutable string causes the following issue.

```
Loading development environment (Rails 5.1.0.alpha)
irb(main):001:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!"
irb(main):002:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!!!"
irb(main):003:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!!!!!"
```

Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?

Example:

    create_table :posts do |t|
      t.datetime :published_at, default: -> { 'NOW()' }
    end

Closes #21418.

Previously schema names were not quoted. This leads to issues when a
schema names contains a ".". Methods in `schema_statements.rb` should
quote user input.

The microseconds handling was already moved to `Quoting#quoted_date`.

We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.

The latest version of the PG gem can actually convert the primitives for
us in C code, which gives a pretty substantial speed up. A few cases
were only there to add the `infinity` method, which I just put on the
range type (which is the only place it was used). Floats also needed to
parse `Infinity` and `NaN`, but it felt reasonable enough to put that on
the generic form.

`quote_default_expression` and `quote_default_value` are almost the same
handling for do not quote default function of `:uuid` columns. Rename
`quote_default_value` to `quote_default_expression`, and remove
duplicate code.

The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:

- `attribute`
  - Lazy (the attribute will be defined after the schema has loaded)
  - Allows either a type object or a symbol
- `define_attribute`
  - Runs immediately (might get trampled by schema loading)
  - Requires a type object

This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).

The goal is to remove the type object from the column, and remove
columns from the type casting process entirely. The primary motivation
for this is clarity. The connection adapter does not have sufficient
type information, since the type we want to work with might have been
overriden at the class level. By taking this object from the column,
it is easy to mistakenly think that the column object which exists on
the connection adapter is sufficient. It isn't.

A concrete example of this is `serialize`. In 4.2 and earlier, `where`
worked in a very inconsistent and confusing manner. If you passed a
single value to `where`, it would serialize it before querying, and do
the right thing. However, passing it as part of an array, hash, or range
would cause it to not work. This is because it would stop using prepared
statements, so the type casting would come from arel. Arel would have no
choice but to get the column from the connection adapter, which would
treat it as any other string column, and query for the wrong value.

There are a handful of cases where using the column object to find the
cast type is appropriate. These are cases where there is not actually a
class involved, such as the migration DSL, or fixtures. For all other
cases, the API should be designed as such that the type is provided
before we get to the connection adapter. (For an example of this, see
the work done to decorate the arel table object with a type caster, or
the introduction of `QueryAttribute` to `Relation`).

There are times that it is appropriate to use information from the
column to change behavior in the connection adapter. These cases are
when the primitive used to represent that type before it goes to the
database does not sufficiently express what needs to happen. An example
of this that affects every adapter is binary vs varchar, where the
primitive used for both is a string. In this case it is appropriate to
look at the column object to determine which quoting method to use, as
this is something schema dependent.

An example of something which would not be appropriate is to look at the
type and see that it is a datetime, and performing string parsing when
given a string instead of a date.  This is the type of logic that should
live entirely on the type. The value which comes out of the type should
be a sufficiently generic primitive that the adapter can be expected to
know how to work with it.

The one place that is still using the column for type information which
should not be necessary is the connection adapter type caster which is
sometimes given to the arel table when we can't find the associated
table. This will hopefully go away in the near future.

Related the commit 8f8f8058.

Move microseconds formatting to `AbstractAdapter`.

Not sure how we missed this case when we moved everything else to the
`_quote` method.

All cases except for `nil` in an array have been removed. `nil` in an
array is handled by the Array type object.

The test case for CVE-2014-3483 doesn't actually send the generated SQL
to the database. The generated SQL is actually invalid for real inputs.