We test the failing case we're trying to patch; only if it throws an
Exception do we patch.

Currently this will *always* throw, but upstream Ruby has patched this
bug: https://git.io/vAxKBSigned-off-by: NAshe Connor <ashe@kivikakk.ee>

URI.unescape "extension" fails with Unicode input

We have a bunch of documentation in
lib/active_support/core_ext/object/json.rb which is currently appearing
as documentation for the top-level ActiveSupport module.  We hide it
from rdoc here.
Signed-off-by: NAshe Connor <ashe@kivikakk.ee>

Previously, URI.enscape could handle Unicode input (without any actual
escaped characters), or input with escaped characters (but no actual
Unicode characters) - not both.

    URI.unescape("\xe3\x83\x90")  # => "バ"
    URI.unescape("%E3%83%90")  # => "バ"
    URI.unescape("\xe3\x83\x90%E3%83%90")  # =>
                                         # Encoding::CompatibilityError

We need to let `gsub` handle this for us, and then force back to the
original encoding of the input.  The result String will be mangled if
the percent-encoded characters don't conform to the encoding of the
String itself, but that goes without saying.
Signed-off-by: NAshe Connor <ashe@kivikakk.ee>

This is an alternate implementation of #31698. That PR makes assumptions
that I do not want in the code base. We can fix the performance
regression with a much simpler patch.

This reverts commit a19e91f0.

mutool is licensed under the Affero GPL, which has strict distribution requirements.

Poppler is licensed under the more liberal GPL, making it a good alternative for those who can't use mutool.

Since we started clearing the client-side blob's type in e0867b36, we no longer need to set a blank Content-Type header before issuing the direct upload request. Fixes that Safari 9 would combine the blank Content-Type header with the blank blob type to produce a Content-Type header containing a single comma, invalidating the request.

Fix dependence on has_one/belongs_to relationships

When a class has a belongs_to or has_one relationship with dependent: :destroy
option enabled, objects of this class should not be deleted if it's dependents
cannot be deleted.

Example:

    class Parent
      has_one :child, dependent: :destroy
    end

    class Child
      belongs_to :parent, inverse_of: :child
      before_destroy { throw :abort }
    end

    c = Child.create
    p = Parent.create(child: c)

    p.destroy

    p.destroyed? # expected: false; actual: true;

Fixes #32022

Follow up of #32151

[Matt Jones & George Claghorn]

Now we always have a terminator, so we don't need to day the options
only make sense when the `:terminator` options is specified.

This issue is caused by `@_trigger_update_callback` won't be updated due
to `_update_record` in `Locking::Optimistic` doesn't call `super` when
optimistic locking is enabled.

Now optimistic locking concern when updating is supported by
`_update_row` low level API, therefore overriding `_update_record` is no
longer necessary.

Removing the method just fix the issue.

Closes #29096.
Closes #29321.
Closes #30823.

Fixes #32129.

Remove extra arg passed to `Rails::Command::RoutesTest#run_routes_command`

Related to 6bd33d66

Deprecate safe_level of `ERB.new` in Ruby 2.6

### Summary

In a Rails application using Ruby 2.6.0-dev, when running `bin/rails g migration`
with `RUBYOPT=-w`, an ERB deprecation warnings will be displayed.

```console
% ruby -v
ruby 2.6.0dev (2018-03-03 trunk 62644) [x86_64-darwin17]
% bin/rails -v
Rails 6.0.0.alpha
% RUBYOPT=-w bin/rails g migration create_foos

(snip)

/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing eoutvar with the 4th argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, eoutvar: ...)
instead.
      create    db/migrate/20180304002144_create_foos.rb
```

This PR suppresses the above deprecation warnings in Ruby 2.6.0-dev.

This warning is due to the interface of `ERB.new` will change from Ruby 2.6.

> Add :trim_mode and :eoutvar keyword arguments to ERB.new.
> Now non-keyword arguments other than first one are softly deprecated
> and will be removed when Ruby 2.5 becomes EOL. [Feature #14256]

https://github.com/ruby/ruby/blob/2311087b685e8dc0f21f4a89875f25c22f5c39a9/NEWS#stdlib-updates-outstanding-ones-only

The following addresses are related Ruby's commit.
https://github.com/ruby/ruby/commit/cc777d0

Also this PR will change `ERB.new` used in `tasks/release.rb`.

### Other Information

This PR uses `ERB.version` to switch `ERB.new` interface. Because Rails 6
supports multiple Ruby versions (Ruby 2.4.1 or higher), it need to
use the appropriate interface.

Using `ERB.version` instead of `RUBY_VERSON` is based on the following patch.
https://github.com/ruby/ruby/pull/1826

This patch is built into Ruby.
https://github.com/ruby/ruby/commit/40db89c0934c23d7464d47946bb682b9035411f9

Currently primary key value can not be updated if a record has a locking
column because of `_update_record` in `Locking::Optimistic` doesn't
respect `id_in_database` as primary key value unlike in `Persistence`.

And also, if a record has dirty primary key value, it may destroy any
other record by the lock version of dirty record itself.

When updating/destroying persisted records, it should identify
themselves by `id_in_database`, not by dirty primary key value.

The `host` and `port` can't use this context.

Convert the user to atheism by ditching the extra example that demonstrates
the same thing as date_of_birth.

Demonstrate the NoMethodError on date_of_birth first, then call age that
uses date_of_birth internally. Thus showing that accessing it publicly fails,
but using it internally succeeds.

Introduce explicit rails server handler option

Fix occurrences Fixnum|Bignum

Fix actionview tests execution

Related to https://github.com/rails/rails/commit/d4eb0dc89ee6b476e2e10869dc282a96f956c6c7#r27830891