This is to be consistent with the way the mysql2 adapter times queries

When the adapter is with prepared statement disabled and the binds array
is not empty the connection adapter will try to set the binds values and
will fail. Now we are checking if the adapter has the prepared statement
disabled.

Fixes #12023

This reverts commit 521035af, reversing
changes made to 222011db.

Reason: This broke the tests

* dependencies/autoload
* concern
* deprecation

It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.

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.

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.