Rack cors initializer is only necessary to API-only applications, for when the update is unnecessary.

Puma 3.0 and up introduced compatibility to read from `config/puma.rb` when booting from the command `$ rails server`https://github.com/puma/puma/pull/856.

- We will remove the initializer for old apps which are migrated to
  Rails 5 so that they are not affected by this breaking change.

This also marks Action Cable routes as internal to Rails.

- app generate option --skip-sprockets leaves jquery-rails gem, which relies on sprockets environment
- Remove jquery-rails if --skip-sprockets is true

Fixes #23431

Redis now included in Gemfile but commented out. This change was made in
91864439 and is causing the test
failure.

See https://travis-ci.org/rails/rails/jobs/106994913#L1025

Test of Rails API should be in `api_app_generator_test.rb`.

This new adapter does get a little more intimate with the redis-rb gem's
implementation than I would like, but it's the least bad of the
approaches I've come up with.

When the `puma` command is run without any configuration options it will detect presence of a `config/puma.rb` file and use that. Currently there is discrepancy between `puma` command and `rails server` but Evan said it would be reasonable to add in reading in config from the default location. I am working on that right now as a feature in puma/puma.

Why do we need this? By default Puma uses 16 threads, and by default ActiveRecord only has 5 threads. Due to the architecture of AR it is guaranteed that if you're running with fewer DB connections than your server has threads you will hit `ActiveRecord::ConnectionTimeoutError ` eventually if your app gets modest amounts of traffic. Since we are providing a default webserver, we should provide reasonable configuration for that webserver.

This PR does a few things, first it sets the default Puma thread count to 5 to mach ActiveRecord's default. It sets the default environment to `"development"` and the default port to 300 so that booting the server with `$ puma` will give you the same default port as `rails server`. It is worth mentioning that by reading in from `PORT` environment variable this config can work with containerized deployments, such as on Heroku. 

We are not using worker processes by default, that way JRuby and windows devs can use this configuration without modification. I went ahead and included a default `on_worker_boot`. It won't be used unless a worker count is specified, that means this config will not use it. Even though it's not being used now It will make someone who wants to try modifying their config to run extra workers easier.

cc/ @pixeltrix

It was removed by mistake at 877a411d

`rack-cors` gem is defined in Gemfile by default only if the api,
not defined by default in rails app.

The Action Cable generators creates four files which need to be removed
if `skip_action_cable` is set.

1. `app/assets/javascripts/cable.coffee`
2. `app/channels/application_cable/channel.rb`
3. `app/channels/application_cable/connection.rb`
4. `config/redis/cable.yml`

Fixes #22669.

It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.

Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.

Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.

Web Console 3.0.0 is compatible with Rails 5, while the 2.x.x releases
aren't.

We are using the same version constraint in the database adapters so
when a new version of the adapter that doesn't work with the version of
rails is released we don't break new applications.

fixes #20042

A lot of scripts assumes the existence of this folder and most would fail if it
is absent.

One example of this is `rake restart` (before the previous commit) – it tries to
`touch tmp/restart.txt`, which would fail if `tmp` does not exist, which was the
case for a freshly-cloned project as `tmp` is `.gitignored` by default.

See #20299.

[Yoong Kang Lim, Sunny Juneja]

Spring seems like an obvious foot gun for the `--dev` setup, presumably you are
about to make lots of changes to the codebase, so it should always reload the
framework.

* Jobs generated now inherent from ApplicationJob
* ApplicationJob inherents from ActiveJob::Base
* Added entry to changelog
Signed-off-by: NJeroen van Baarsen <jeroenvanbaarsen@gmail.com>

Deprecate `required` option in favor of `optional` for belongs_to.

README.rdoc was generated to support the doc:app task. Now that
this task is gone we can switch to Markdown, which is nowadays
a better default.

This patch removes the tasks doc:app, doc:rails, and doc:guides.

In our experience applications do not generate APIs using doc:app.
Methods may be certainly documented for maintainers, annotated
with YARD tags, etc. but that is intended to be read with the
source code, not in a separate website. Then, teams also have
typically selected topics written down in Markdown files, or in
a GitHub wiki... that kind of thing.

If a team absolutely needs to generate application documentation
for internal purposes, they can still easily write their own task.

Regarding doc:rails and doc:guides, we live in 2015. We are used
to go to online docs all the time. If you really want access to the
API offline RubyGems generates it for every Rails component unless
you tell it not to, and you can checkout the Rails source code to
read the guides as Markdown, or download them for a Kindle reader.

All in all, maintaining this code does not seem to be worthwhile
anymore.

As a consequence of this, guides (+3 MB uncompressed) won't be
distributed with the rails gem anymore. Of course, guides and API
are going to be still part of releases, since documentation is
maintained alongside code and tests.

Also, time permitting, this will allow us to experiment with novel
ways to generate documentation in the Rails docs server, since
right now we were constrained by being able to generate them in
the user's environment.

It's a thin layer to provide easy access to sample files throughout
test-cases. This adds the directory `test/fixtures/files` to newly
generated applications.

Rails no longer generates Test::Unit files by default.