Avoid LazilyDefinedAttributes being included multiple times in class, and remove methods after first use

Don't round off subseconds unless necessary

Recover perf for `pluck` by reverting 9c9c950d…

If we want to get alias resolved attribute finally, we can use
`attribute_alias` directly.

For that purpose, avoiding redundant `attribute_alias?` makes alias
attribute access 40% faster.

https://gist.github.com/kamipo/e427f080a27b46f50bc508fae3612a0e

Before (2c0729d8):

```
Warming up --------------------------------------
          user['id']   102.668k i/100ms
      user['new_id']    80.660k i/100ms
        user['name']    99.368k i/100ms
    user['new_name']    81.626k i/100ms
Calculating -------------------------------------
          user['id']      1.431M (± 4.0%) i/s -      7.187M in   5.031985s
      user['new_id']      1.042M (± 4.2%) i/s -      5.243M in   5.039858s
        user['name']      1.406M (± 5.6%) i/s -      7.055M in   5.036743s
    user['new_name']      1.074M (± 3.6%) i/s -      5.387M in   5.024152s
```

After (this change):

```
Warming up --------------------------------------
          user['id']   109.775k i/100ms
      user['new_id']   103.303k i/100ms
        user['name']   105.988k i/100ms
    user['new_name']    99.618k i/100ms
Calculating -------------------------------------
          user['id']      1.520M (± 6.7%) i/s -      7.574M in   5.011496s
      user['new_id']      1.485M (± 6.2%) i/s -      7.438M in   5.036252s
        user['name']      1.538M (± 5.4%) i/s -      7.737M in   5.049765s
    user['new_name']      1.516M (± 4.6%) i/s -      7.571M in   5.007293s
```

The current comment here is from 2011 and its original context has
changed completely. The plain matcher will not "match every time"
anymore since the code now filters all matchers, and only selects those
for which the captured attribute is valid.

To avoid confusion, I updated the comment. For more discussion, see:

https://github.com/rails/rails/pull/36005

This adds `.attribute_names` and `#attribute_names` to
`ActiveModel::Attributes` along the same lines as the corresponding
methods in `ActiveRecord::AttributeMethods` (see
[`.attribute_names`][class_method] and
[`#attribute_names`][instance_method].

While I was here I also added documentation for '#attributes', which I
added in 043ce35b. The whole class is still `#:nodoc:` so I don't
think this will have any effect for now.

[class_method]: https://github.com/rails/rails/blob/cc834db1d0815744cfa173813c05d928e008e167/activerecord/lib/active_record/attribute_methods.rb#L154-L160
[instance_method]: https://github.com/rails/rails/blob/cc834db1d0815744cfa173813c05d928e008e167/activerecord/lib/active_record/attribute_methods.rb#L299-L301

Most of the time, these methods are called from actual methods defined
from columns in the schema, not from method_missing, so the current
wording is misleading.

The target of matchers is used in two contexts: to define attribute
methods which dispatch to handlers like attribute_was, and to match
method calls in method_missing and dispatch to those same handler
methods.

Only in the latter context does the term "method_missing_target" make
any sense; in the former context it is just confusing. "target" is not
ideal as a term but at least it avoids this confusion.

Currently, although using both dirty tracking (ivar backed and
attributes backed) on one model is not supported (doesn't fully work at
least), both dirty tracking are being performed, that is very slow.

As long as attributes backed dirty tracking is used, ivar backed dirty
tracking should not need to be performed.

I've refactored to extract new `ForcedMutationTracker` which only tracks
`force_change` to be performed for ivar backed dirty tracking, that
makes dirty tracking on Active Record 2x ~ 30x faster.

https://gist.github.com/kamipo/971dfe0891f0fe1ec7db8ab31f016435

Before:

```
Warming up --------------------------------------
            changed?     4.467k i/100ms
             changed     5.134k i/100ms
             changes     3.023k i/100ms
  changed_attributes     4.358k i/100ms
        title_change     3.185k i/100ms
           title_was     3.381k i/100ms
Calculating -------------------------------------
            changed?     42.197k (±28.5%) i/s -    187.614k in   5.050446s
             changed     50.481k (±16.0%) i/s -    246.432k in   5.045759s
             changes     30.799k (± 7.2%) i/s -    154.173k in   5.030765s
  changed_attributes     51.530k (±14.2%) i/s -    252.764k in   5.041106s
        title_change     44.667k (± 9.0%) i/s -    222.950k in   5.040646s
           title_was     44.635k (±16.6%) i/s -    216.384k in   5.051098s
```

After:

```
Warming up --------------------------------------
            changed?    24.130k i/100ms
             changed    13.503k i/100ms
             changes     6.511k i/100ms
  changed_attributes     9.226k i/100ms
        title_change    48.221k i/100ms
           title_was    96.060k i/100ms
Calculating -------------------------------------
            changed?    245.478k (±16.1%) i/s -      1.182M in   5.015837s
             changed    157.641k (± 4.9%) i/s -    796.677k in   5.066734s
             changes     70.633k (± 5.7%) i/s -    358.105k in   5.086553s
  changed_attributes     95.155k (±13.6%) i/s -    470.526k in   5.082841s
        title_change    566.481k (± 3.5%) i/s -      2.845M in   5.028852s
           title_was      1.487M (± 3.9%) i/s -      7.493M in   5.046774s
```

Follow up of #26764 and #35700.

And add test case for #35700.

Before 34cc301f, type casting by boolean attribute when querying is a
no-op, so finding by truthy boolean string (i.e.
`where(value: "true") # => value = 'true'`) didn't work as expected
(matches it to FALSE in MySQL #32624). By type casting is ensured, a
value on boolean attribute is always serialized to TRUE or FALSE.

In PostgreSQL, `where(value: :false) # => value = 'false'` was a valid
SQL, so 34cc301f is a regresson for PostgreSQL since all symbol values
are serialized as TRUE.

I'd say using `:false` is mostly a developer's mistake (user's input
basically comes as a string), but `:false` on boolean attribute is
serialized as TRUE is not a desirable behavior for anybody.

This allows falsy boolean symbols as false, i.e.
`klass.create(value: :false).value? # => false` and
`where(value: :false) # => value = FALSE`.

Fixes #35676.

- I feel `i18n_customize_full_messages` explains the meaning of the
  config better.
- Followup of https://github.com/rails/rails/pull/32956

In Rails 5.2.x calling `has_secure_password` would define attribute
readers and writers on the superclass of the model, which meant that you
could override these attributes in a model and call the superclass for
example:

```
class Dog < ApplicationRecord
  has_secure_password

  def password=(new_password)
    @password_set = new_password.present?
    super
  end
end
```

However this behaviour was broken in Rails 6 when the ability to
customise the name of the attribute was introduced [1] since they are no
longer being defined on the superclass you will now see the following
error:

```
NoMethodError:
super: no superclass method `password=' for #<Dog:0x00007ffbbc7ce290>
Did you mean?  password
```

In order to resolve this issue and retain support for setting a custom
attribute name we can define these attribute readers/writers in a module
and then ensure that the module is included in the inheritance chain.

[1] https://www.github.com/rails/rails/commit/86a48b4da3
    https://www.github.com/rails/rails/commit/9b63bf1dfd

* Update RAILS_VERSION
* Bundle
* rake update_versions
* rake changelog:header

This reverts commit 52fddcc6.

52fddcc6 was to short-circuit `ensure_in_range` in `cast_value`. But that
caused a regression for empty string deserialization.

Since 7c6f3938, `ensure_in_range` is moved into `serialize`. As 52fddcc6
said, the absolute gain is quite small. So I've reverted that commit to
fix the regression.

This is a follow-up of #35310.

Currently `Topic.find_by(id: "not-a-number")` matches to a `id = 0`
record. That is considered as silently leaking information.

If non numeric string is given to find by an integer column, it should
not be matched to any record.

Related #12793.

That is considered as silently leaking information.
If type casting doesn't return any actual value, it should not be
matched to any record.

Fixes #33624.
Closes #33946.

Since `serialize` is passed user input args (from `where`, schema
default, etc), a helper should provide `serialize` if the helper also
provide `cast`.

Related #32624, 34cc301f, a741208f.

`value_from_multiparameter_assignment` defined by
`AcceptsMultiparameterTime` helper requires `default_timezone` method
which is defined at `TimeValue` helper.
Since `Date` type doesn't include `TimeValue`, I've extracted `Timezone`
helper to be shared by `Date`, `DateTime`, and `Time` types.

In master, tests pass because `bigdecimal/util` requires in
`active_support/xml_mini`.
But test fails in 5-2-stable because that require does not exist.
Ref: https://travis-ci.org/rails/rails/jobs/484627996#L1969

- If you had a PORO that acted like a Numeric, the validator would
  work correctly because it was previously using `Kernel.Float`
  which is implicitely calling `to_f` on the passed argument.

  Since rails/rails@d126c0d , we are now using `BigDecimal` which does
  not implicitely call `to_f` on the argument, making the validator
  fail with an underlying `TypeError` exception.

  This patch replate the `is_decimal?` check with `Kernel.Float`.
  Using `Kernel.Float` as argument for the BigDecimal call has two
  advantages:

  1. It calls `to_f` implicetely for us.
  2. It's also smart enough to detect that `Kernel.Float("a")` isn't a
     Numeric and will raise an error.
     We don't need the `is_decimal?` check thanks to that.

  Passing `Float::DIG` as second argument to `BigDecimal` is mandatory
  because the precision can't be omitted when passing a Float.
  `Float::DIG` is what is used internally by ruby when calling
  `123.to_d`

  https://github.com/ruby/ruby/blob/trunk/ext/bigdecimal/lib/bigdecimal/util.rb#L47

- Another small issue introduced in https://github.com/rails/rails/pull/34693
  would now raise a TypeError because `Regexp#===` will just return
  false if the passed argument isn't a string or symbol, whereas
  `Regexp#match?` will.

When assigning a hash to a time attribute that's missing a year
component (e.g. a `time_select` with `:ignore_date` set to `true`)
then the year defaults to 1970 instead of the expected 2000. This
results in the attribute changing as a result of the save.

Before:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 1970-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC

After:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 2000-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC