Merge pull request #15550 from sgrif/sg-numeric-types

Don't mess with `_before_type_cast` for numeric types
Revert "Merge pull request #15550 from sgrif/sg-numeric-types"

This reverts commit be1db9946616a4005bb7be45656cc0f84d75d915, reversing
changes made to 6680ee9427ae2639e404cd3b9538f54e136057c6.

Reason: This changed a behavior where numeric attributes when receiving
blank values didn't change its value.
eliminate wasteful AS::SafeBuffer allocation
remove another wasteful AS::SafeBuffer allocation
Don't mess with `_before_type_cast` for numeric types
Remove composed_of special case from multi-parameter attributes

As we move towards removing the `klass` method from `column`, the else
clause as it stands right now will become the only case.
Merge pull request #15551 from sgrif/sg-numeric-types

Don't mess with `_before_type_cast` for numeric types
Merge pull request #15552 from sgrif/sg-remove-klass-special-case

Remove composed_of special case from multi-parameter attributes
eliminate more wasteful allocations
Removed unused `klass` definitions from types

Only `Date` and `Time` are handled.
Merge pull request #15554 from sgrif/sg-klass

Removed unused `klass` definitions from types
Unwrap another html_escape

/cc @tenderlove
Merge pull request #15542 from Gaurav2728/gaurav-remove_shutdown_link

remove rubyforge.org that was shut down [ci skip]
[ci skip] Fix capitalization
Merge pull request #15555 from akshay-vishnoi/doc_changes

Fix capitalization
Merge branch 'master' of github.com:rails/docrails
copy edits [ci skip]
Revert "Convert StrongParameters cache to a hash. This fixes an unbounded"

We cannot cache keys because arrays are mutable. We rather want to cache
the arrays. This behaviour is tailor-made for the usage pattern strongs
params is designed for.

In a forthcoming commit I am going to add a test that covers why we need
to cache by value.

Every strong params instance has a live span of a request, the cache goes
away with the object. Since strong params have such a concrete intention,
it would be interesting to see if there are actually any real-world use
cases that are an actual leak, one that practically may matter.

I am not convinced that the theoretical leak has any practical consequences,
but if it can be shown there are, then I believe we should either get rid of
the cache (which is an optimization), or else wipe it in the mutating API.

This reverts commit e63be2769c039e4e9ada523a8497ce3206cc8a9b.
adds a regression test for the strong params converted arrays cache

This is a regression test for 29844dd.
adds some details to the rationale of converted_arrays [ci skip]