Fixes #18580.

Fixes #18632

Keeping with our behavior elsewhere in the system, invalid input is
assumed to be `nil`.

Fixes #18629.

This method can be used to see all of the fields on a model which have
been read. This can be useful during development mode to quickly find
out which fields need to be selected. For performance critical pages, if
you are not using all of the fields of a database, an easy performance
win is only selecting the fields which you need. By calling this method
at the end of a controller action, it's easy to determine which fields
need to be selected.

While writing this, I also noticed a place for an easy performance win
internally which I had been wanting to introduce. You cannot mutate a
field which you have not read. Therefore, we can skip the calculation of
in place changes if we have never read from the field. This can
significantly speed up methods like `#changed?` if any of the fields
have an expensive mutable type (like `serialize`)

```
Calculating -------------------------------------
 #changed? with serialized column (before)
                       391.000  i/100ms
 #changed? with serialized column (after)
                         1.514k i/100ms
-------------------------------------------------
 #changed? with serialized column (before)
                          4.243k (± 3.7%) i/s -     21.505k
 #changed? with serialized column (after)
                         16.789k (± 3.2%) i/s -     84.784k
```

If set to `if_exists: true`, it generates a statement like:

    DROP TABLE IF EXISTS posts

This syntax is supported in the popular SQL servers, that is (at least)
SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever.

Closes #16366.

 - This is based on https://github.com/rails/rails/issues/18400 but
   tackling same issue with update_attribute method instead of update method.

after_commit callbacks run after committing a transaction whose parent
is not `joinable?`: un-nested transactions, transactions within test
cases, and transactions in `console --sandbox`.

The types that are affected by `time_zone_aware_attributes` (which is on
by default) have been made configurable, in case this is a breaking
change for existing applications.

There's very little value in logging "<NULL binary data>" instead of
just "nil". I'd like to remove the column from the equation entirely,
and this case is preventing us from doing so.

This sets a precident for how we handle `attribute` calls, which aren't
backed by a database column. We should not take this as a conscious
decision on how to handle them, and this can change when we make
`attribute` public if we have better ideas in the future.

As the composed attributes API gets fleshed out, I expect the
`persistable_attributes` method to change to
`@attributes.select(&:persistable).keys`, or some more performant
variant there-of. This can probably go away completely once we fully
move dirty checking into the attribute objects once it gets moved up to
Active Model.

Fixes #18407

Related to #10690.

 - Fixtures with non-string labels such as integers should be accessed
   using integer label as key. For eg. pirates(1) or pirates(42).
 - But this results in NotFound error because the label is converted into string before
   looking up into the fixtures hash.
 - After this commit, the label is converted into string only if its a
   symbol.
 - This issue was fount out while adding a test case for
   https://github.com/rails/rails/commit/7b910917.

Addresses https://github.com/rails/rails/commit/ed56e596a0467390011bc9d56d462539776adac1#commitcomment-9145960

addresses https://github.com/rails/rails/commit/91949e48cf41af9f3e4ffba3e5eecf9b0a08bfc3#commitcomment-9144563

This adresses https://github.com/rails/rails/commit/1b7aa62b184c4410c99208f71b59bbac5c5f03be#commitcomment-9147803

Update SecureToken Docs

Add Changelog entry for has_secure_token [ci skip]

Before this change we had a small set of "truthy", and all others
are "falsy".

Now, we have a small set of "falsy" values and all others are
"truthy" matching Ruby's semantics.

Before this change any error raised inside a transaction callback
are rescued and printed in the logs.

Now these errors are not rescue anymore and just bubble up,
as the other callbacks.

Now all strings will be handled as a URL.

This reverts commit ae96f229.

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/lib/active_record/attribute_methods.rb

This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:

* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.

For this purpose, this commit introduces a Rails configuration option:

```ruby
config.active_support.halt_callback_chains_on_return_false
```

For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:

```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```

For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.

Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.

Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.

A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931

Before this commit, returning `false` in an ActiveRecord `before_` callback
such as `before_create` would halt the callback chain.

After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.

The preferred way to halt a callback chain is to explicitly `throw(:abort)`.

Incompatible to rounding behavior between MySQL 5.6 and earlier.

In 5.5, when you insert `2014-08-17 12:30:00.999999` the fractional part
is ignored. In 5.6, it's rounded to `2014-08-17 12:30:01`:

http://bugs.mysql.com/bug.php?id=68760

This error only happens when the foreign key is missing.

Before this fix the following exception was being raised:

    NoMethodError: undefined method `val' for #<Arel::Nodes::BindParam:0x007fc64d19c218>

Now the message is:

    ActiveRecord::UnknownAttributeError: unknown attribute 'foreign_key' for Model.

 - Improved wording of CHANGELOG entry for https://github.com/arthurnn/rails/commit/5acd24bbeae0e9e5e81e87b5929e17f35527b2ea.