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

On my local environment execution of `cd actionview/ && bin/test` raises error:

```
(snip)
rails/actionview/test/template/render_test.rb:6:in `<top (required)>': superclass mismatch for class TestController (TypeError)
```

In some test files `TestController` inherited from `ActionController::Base`,
but in `test/actionpack/controller/render_test.rb` file `TestController`
inherited from `ApplicationController`.
This produces error `superclass mismatch for class TestController (TypeError)`

Step to reproduce this on any environment:
`cd actionview/ && bin/test test/template/streaming_render_test.rb test/actionpack/controller/render_test.rb`

I mistype `rails server production` instead of `rails server -e
production` expecting to lunch a server in the production environment
all the time. However, the signature of `rails server --help` is:

```
Usage:
  rails server [puma, thin etc] [options]
```

This means that the `production` argument is being interpreted as a Rack
server handler like Puma, Thin or Unicorn.

Should we argue for the `rails server production`? I'm not sure of the
reasons, but the `rails console production` behavior was deprecated in:
https://github.com/rails/rails/pull/29358, so parity with the existing
`rails console production` usage may not hold anymore.

In any case, this PR introduces an explicit option for the Rack servers
configuration. The option is called `--using` (or `-u` for short) to
avoid the `rails server --server` tantrum.

The new interface of `rails server` is:

```
Usage:
  rails server [using] [options]

Options:
  -p, [--port=port]                        # Runs Rails on the specified port - defaults to 3000.
  -b, [--binding=IP]                       # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'.
  -c, [--config=file]                      # Uses a custom rackup configuration.
                                           # Default: config.ru
  -d, [--daemon], [--no-daemon]            # Runs server as a Daemon.
  -e, [--environment=name]                 # Specifies the environment to run this server under (development/test/production).
  -u, [--using=name]                       # Specifies the Rack server used to run the application (thin/puma/webrick).
  -P, [--pid=PID]                          # Specifies the PID file.
                                           # Default: tmp/pids/server.pid
  -C, [--dev-caching], [--no-dev-caching]  # Specifies whether to perform caching in development.
      [--early-hints], [--no-early-hints]  # Enables HTTP/2 early hints.
```

As a bonus, if you mistype the server to use, you'll get an
auto-correction message:

```
$ rails s tin
Could not find handler "tin". Maybe you meant "thin" or "cgi"?
Run `rails server --help` for more options.
```

Fix links in the psql guide [ci skip]

Merge Previews/Variants controller into one Representations controller.