Patches `CollectionAssociation#count` to return 0 without querying
if the parent record is new. Consider the following code:

    class Account
      has_many :dossiers
    end

    class Dossier
      belongs_to :account
    end

    a = Account.new
    a.dossiers.build

    # before patch
    a.dossiers.count
    # SELECT COUNT(*) FROM "dossiers" WHERE "dossiers"."account_id" IS NULL
    # => 0

    # after
    a.dosiers.count # fires without sql query
    # => 0

Fixes #1856.

The counter column name in the intermediate model need to be access
via the through reflection.

because Oracle adapter uses upper case attribute/column name.

When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.

This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).

Fix destructive side effects from marshaling an association caused by 65843e1a

i.e. Oracle database does not support these isolation levels.
`:read_uncommitted` `:repeatable_read`

This commit also works with other databases which do not support
these isolation levels.

This commit allows a user to do something like:
    before_validation :do_stuff, :on => [ :create, :update ]
    after_validation :do_more, :on => [ :create, :update ]

Related to 761bc751 and
eb876c4d

This reverts commit 761bc751.

This commit wasn't fixing any issue just using the same table for
different models with different primary keys.

It's too hard to test this properly, so let's just check that there are
no errors.

If your database supports setting the isolation level for a transaction,
you can set it like so:

  Post.transaction(isolation: :serializable) do
    # ...
  end

Valid isolation levels are:

* `:read_uncommitted`
* `:read_committed`
* `:repeatable_read`
* `:serializable`

You should consult the documentation for your database to understand the
semantics of these different levels:

* http://www.postgresql.org/docs/9.1/static/transaction-iso.html
* https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

An `ActiveRecord::TransactionIsolationError` will be raised if:

* The adapter does not support setting the isolation level
* You are joining an existing open transaction
* You are creating a nested (savepoint) transaction

The mysql, mysql2 and postgresql adapters support setting the
transaction isolation level. However, support is disabled for mysql
versions below 5, because they are affected by a bug
(http://bugs.mysql.com/bug.php?id=39170) which means the isolation level
gets persisted outside the transaction.

Closes #6960

If assigning to a has_many :through collection against an unsaved
object using the collection=[<array_of_items>] syntax, the join models
were not properly created, previously.

The COUNT clause of a finder_sql relationship is being rewritten from
COUNT(*) to COUNT(table_name.*). This does not appear to be valid syntax
in MySQL:

```
mysql> SELECT COUNT( table_name.* ) FROM `table_name`;
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near '* ) FROM `table_name`' at line 1
```

This fixes the bug, as well as adding tests so we don't re-introduce
it in the future.

Fixes #3956.

Due to its lack of thread safety, we're deprecating this, and it
will be removed in Rails 4.1.

Fixes #4060.

Accidentally checked in commented test code. Fail. >_<

This method was first seen in 045713ee,
and subsequently reimplemented in
fb2325e3.

According to @jeremy, this is okay to remove. He thinks it was added
because at the time we didn't have much transaction state to keep track
of, and he viewed it as a hack for us to track it internally, thinking
it was better to ask the connection for the transaction state.

Over the years we have added more and more state to track, a lot of
which is impossible to ask the connection for. So it seems that this is
just a relic of the passed and we will just track the state internally
only.

Having column related schema dumper code in the AbstractAdapter. The
code remains the same, but by placing it in the AbstractAdapter, we can
then overwrite it with Adapter specific methods that will help with
Adapter specific data types.

The goal of moving this code here is to create a new migration key for
PostgreSQL's array type. Since any datatype can be an array, the goal is
to have ':array => true' as a migration option, turning the datatype
into an array. I've implemented this in postgres_ext, the syntax is
shown here: https://github.com/dockyard/postgres_ext#arrays

Adds array migration support

Adds array_test.rb outlining the test cases for array data type
Adds pg_array_parser to Gemfile for testing
Adds pg_array_parser to postgresql_adapter (unused in this commit)

Adds schema dump support for arrays

Adds postgres array type casting support

Updates changelog, adds note for inet and cidr support, which I forgot to add before

Removing debugger, Adds pg_array_parser to JRuby platform

Removes pg_array_parser requirement, creates ArrayParser module used by
PostgreSQLAdapter