`BigDecimal.new` has been deprecated in BigDecimal 1.3.3
 which will be a default for Ruby 2.5.

Refer
https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503

* This commit has been made as follows:

```
cd rails
git grep -l BigDecimal.new | grep -v guides/source/5_0_release_notes.md | grep -v activesupport/test/xml_mini_test.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g"
```
- `activesupport/test/xml_mini_test.rb`
Editmanually to remove `.new` and `::`

- guides/source/5_0_release_notes.md
This is a Rails 5.0 release notes.

Follow up of #31432.

and defaults to `Digest::MD5`.

Replaced calls to `::Digest::MD5.hexdigest` with calls to `ActiveSupport::Digest.hexdigest`.

Follow up of #31390.

Matches Hash#each behaviour as used in Rails 4.

As `@cache_path` is expected to be a directory name, use `Dir.mktmpdir`.
And omit unnecessary `Dir.tmpdir`.

Instead of `Dir::Tmpname.make_tmpname`, an internal method which does not guarantee uniqueness, use `Tempfile.create`.

Currently `:api:` tag has leaked on the doc directly since RDoc doesn't
support `:api:` tag directive.

http://api.rubyonrails.org/v5.1/classes/AbstractController/Rendering.html

So `:api: private` doesn't work as expected. We are using `:nodoc:` for
the purpose.

Related #13989.

Using the action_dispatch.cookies_rotations interface, key rotation is
now possible with cookies. Thus the secret_key_base as well as salts,
ciphers, and digests, can be rotated without expiring sessions.

In the existing logic, the `Cache-Control` header may or may not get
normalized by additional logic depending on whether `response.cache_conrol`
has been modified. This leads to inconsistent behavior, since sometimes
`Cache-Control` can contain whatever a user sets and sometimes it gets
normalized, based on the logic inside of `set_conditional_cache_control!`. It
seems like this normalization process should happen regardless to ensure
consistent behavior.

And enable `context_dependent` of Style/BracesAroundHashParameters cop.

This commit changes the behavior such the path_params now default to
UTF8 just like regular parameters. This also changes the behavior such
that if a path parameter contains invalid UTF8 it returns a 400 bad
request. Previously the behavior was to encode the path params as binary
but that's not the same as query params.

So this commit makes path params behave the same as query params.

It's important to test with a path that's encoded as binary because
that's how paths are encoded from the socket. The test that was altered
was changed to make the behavior for bad encoding the same as query
params. We want to treat path params the same as query params. The params
in the test are invalid UTF8 so they should return a bad request.

Fixes #29669

*Eileen M. Uchitelle, Aaron Patterson, & Tsukuru Tanimichi*

Since we now default to `protect_from_forgery with: :exception`,
provide a wrapper to `skip_before_action :verify_authenticity_token`
for disabling forgery protection.

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

Fixes https://github.com/rails/rails/issues/29617

- When making a request to a controller that redirects, `follow_redirect!` would not reset the `html_document` ivar, it only resets the `html_document` ivar from the session (not the runner)
- If one was doing something like this;
  ```ruby
    get '/redirect'
    assert_select 'you are being redirected'
    follow_redirect!
    # html_document is memoized and doesn't get reset
  ```
- To fix the issue we can do the same for any other methods (`get`, `post`...) and define a method in the runner that delegates to the session but clears the html_document_first
- Fixes #29367

We want to avoid overwriting a query parameter with the wrapped
parameters hash. Previously this was implemented by merging the wrapped
parameters at the root level if the key already existed, which was
effectively a no-op. The query parameter was still overwritten in the
filtered parameters hash, however.

We can fix that discrepancy with a simpler implementation and less
unnecessary work by skipping parameter wrapping entirely if the key was
sent as a query parameter.

We shouldn't perform parameter wrapping if it would overwrite one of the
parameters sent with the request, as that would interfere with reading
the parameter directly from the top level `params` hash.

The current implementation has logic for this case, but it doesn't
handle `nil`/`false` values, which means these parameters:

    { "user" => nil }

are transformed into this `params` hash:

    { "user" => { "user" => nil } }

and `params["user"]` no longer returns the original parameter value.

".. with __dir__ we can restore order in the Universe." - by @fxn

Related to 5b8738c2