I've realized that `user.id` is 20% slower than `user.name` in the
benchmark (https://github.com/rails/rails/pull/35987#issuecomment-483882480).

The reason that performance difference is that `self.class.primary_key`
method call is a bit slow.

Avoiding that method call will make almost attribute access faster and
`user.id` will be completely the same performance with `user.name`.

Before (02b5b8cb):

```
Warming up --------------------------------------
             user.id   140.535k i/100ms
          user['id']    96.549k i/100ms
           user.name   158.110k i/100ms
        user['name']    94.507k i/100ms
       user.changed?    19.003k i/100ms
 user.saved_changes?    25.404k i/100ms
Calculating -------------------------------------
             user.id      2.231M (± 0.9%) i/s -     11.243M in   5.040066s
          user['id']      1.310M (± 1.3%) i/s -      6.565M in   5.012607s
           user.name      2.683M (± 1.2%) i/s -     13.439M in   5.009392s
        user['name']      1.322M (± 0.9%) i/s -      6.615M in   5.003239s
       user.changed?    201.999k (±10.9%) i/s -      1.007M in   5.091195s
 user.saved_changes?    258.214k (±17.1%) i/s -      1.245M in   5.007421s
```

After (this change):

```
Warming up --------------------------------------
             user.id   158.364k i/100ms
          user['id']   106.412k i/100ms
           user.name   158.644k i/100ms
        user['name']   107.518k i/100ms
       user.changed?    19.082k i/100ms
 user.saved_changes?    24.886k i/100ms
Calculating -------------------------------------
             user.id      2.768M (± 1.1%) i/s -     13.936M in   5.034957s
          user['id']      1.507M (± 2.1%) i/s -      7.555M in   5.017211s
           user.name      2.727M (± 1.5%) i/s -     13.643M in   5.004766s
        user['name']      1.521M (± 1.3%) i/s -      7.634M in   5.018321s
       user.changed?    200.865k (±11.1%) i/s -    992.264k in   5.044868s
 user.saved_changes?    269.652k (±10.5%) i/s -      1.344M in   5.077972s
```

This partly reverts 8ca3c286.

`.is_a?(GeneratedAttributeMethodsBuilder)` doesn't make sense to me, the
module class's `new` creates just an instance of the module class itself.

Currently GeneratedAttributeMethods is a module builder class, an
instance of which is included in every AR class. OTOH,
GeneratedAssociatedMethods is assigned to a constant under the model
namespace. This is inconsistent and looks strange in the list of
ancestors.

There is no particular reason *not* to assign a constant for this (very
important) module under the model namespace, so that's what this commit
does.

Previous to this change, ancestors for an AR class looked like this:

```
=> [User (call 'User.connection' to establish a connection),
 User::GeneratedAssociationMethods,
 #<ActiveRecord::AttributeMethods::GeneratedAttributeMethods:0x000055ace0f05b08>,
 ApplicationRecord(abstract),
 ApplicationRecord::GeneratedAssociationMethods,
 #<ActiveRecord::AttributeMethods::GeneratedAttributeMethods:0x000055ace093c460>,
 ActiveRecord::Base,
 ...
```

With this change, they look like this:

```
=> [User (call 'User.connection' to establish a connection),
 User::GeneratedAssociationMethods,
 User::GeneratedAttributeMethods,
 ApplicationRecord(abstract),
 ApplicationRecord::GeneratedAssociationMethods,
 ApplicationRecord::GeneratedAttributeMethods,
 ActiveRecord::Base,
 ...
```

The previously named `GeneratedAttributeMethods` module builder class is
renamed `GeneratedAttributeMethodsBuilder` to emphasize that this is not
a module but a class.

The `read_attribute` method always returns the primary key when asked to
read the `id` attribute, even if the primary key isn't named `id`, and
even if another attribute named `id` exists.

For the `inspect`, `attribute_for_inspect` and `pretty_print` methods,
this behaviour is undesirable, as they're used to examine the internal
state of the record. By using `_read_attribute` instead, we'll get the
real value of the `id` attribute.

AR instance support `filter_parameters` since #33756.
Though Regex or Proc is valid as `filter_parameters`,
they are not supported as AR#inspect.

I also add :mask option and #filter_params to
`ActiveSupport::ParameterFilter#new` to implement this.

This is an alternative to https://github.com/rails/rails/pull/34195

The active record `respond_to?` method needs to do two things if `super` does not say that the method exists. It has to see if the "name" being passed in represents a column in the table. If it does then it needs to pass it to `has_attribute?` to see if the key exists in the current object. The reason why this is slow is that `has_attribute?` needs a string and most (almost all) objects passed in are symbols.

The only time we need to allocate a string in this method is if the column does exist in the database, and since these are a limited number of strings (since column names are a finite set) then we can pre-generate all of them and use the same string. 

We generate a list hash of column names and convert them to symbols, and store the value as the string name. This allows us to both check if the "name" exists as a column, but also provides us with a string object we can use for the `has_attribute?` call. 

I then ran the test suite and found there was only one case where we're intentionally passing in a string and changed it to a symbol. (However there are tests where we are using a string key, but they don't ship with rails).

As re-written this method should never allocate unless the user passes in a string key, which is fairly uncommon with `respond_to?`.

This also eliminates the need to special case every common item that might come through the method via the `case` that was originally added in https://github.com/rails/rails/commit/f80aa5994603e684e3fecd3f53bfbf242c73a107 (by me) and then with an attempt to extend in https://github.com/rails/rails/pull/34195.

As a bonus this reduces 6,300 comparisons (in the CodeTriage app homepage) to 450 as we also no longer need to loop through the column array to check for an `include?`.

Ruby uses the original method name, so will show the __temp__ method
name in the backtrace. However, in the common case the method name
is compatible with the `def` keyword, so we can avoid the __temp__
method name in that case to improve the name shown in backtraces
or TracePoint#method_id.

Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.

* Exclude these files not to auto correct false positive `Regexp#freeze`
 - 'actionpack/lib/action_dispatch/journey/router/utils.rb'
 - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'

It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.

* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required

 - 'actionpack/test/controller/test_case_test.rb'
 - 'activemodel/test/cases/type/string_test.rb'
 - 'activesupport/lib/active_support/core_ext/string/strip.rb'
 - 'activesupport/test/core_ext/string_ext_test.rb'
 - 'railties/test/generators/actions_test.rb'

Use `delete_if` instead of `reject` to avoid an extra allocation.

`attributes_with_values_for_update` is no longer used since ae2d36cf, and
`attributes_with_values_for_create` is internally used only one place.

When requesting columns names from database adapters AR:Result
would dup/freeze column names, this prefers using fstrings which
cuts down on repeat allocations

Attributes that are retained keep these fstrings around for the long
term

Note, this has the highest impact on "short" result sets, eg: Topic.first where you can void allocating the number of columns * String.

Since #32028, Rails 6 requires Ruby 2.3+.
No longer needed workaround for Ruby 2.2 "private attribute?" warning.

It is useless since 90c8be76.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

`display_deprecation_warning_for_false_terminator` was removed since
3a25cdca.

All indentation was normalized by rubocop auto-correct at 80e66cc4.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.

Some case expressions remain, need to think about those ones.