[close #23681] Use puma 3.0.0+

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.

Changed debugging rails app doc.

- Changed Debugging Rails Applications doc's logger introduction section. Changed location for specifying logger.
[Prajakta, thiagoaugusto]

fix typo in pull_request_template [ci skip]

[skip ci]

If we're deferring one, we should defer the other too.

Add `issue_template.md`

Enable HSTS with IncludeSubdomains header by default for new apps

correctly check `ApplicationRecord` is exist in moutable engine

Fix uniqueness validation with an after_create hook.

This reverts commit 22db455d, reversing
changes made to 40be61df.

This finishes off what I meant to do in 6216a092.

This reverts commit 45a75a3f.

HWIAs are better than silently deeply-stringified hashes... but that's a
reaction to a shortcoming of one particular session store: we should not
break the basic behaviour of other, more featureful, session stores in
the process.

Fixes #23884

Doc: update guides for Rails 5

[ci skip]

[ci skip]

record.id_was is nil in after_create/after_save, so we should use
id in these cases.

While this logic feels incomplete, the existing update_record uses the same
logic:
https://github.com/rails/rails/blob/2fda4e0874a97a76107ab9e88305169f2c625933/activerecord/lib/active_record/relation.rb#L83

This logic was originally added for a similar problem:
updates not working with after_create hook.

See: 482f8c15

Followup to #23581
Fixes #23844

[ci skip] Update configuration guide

* Fixes typos in error message and release notes.
* Removes unused template test file.

Lock down new `ImplicitRender` behavior for 5.0 RC

1. Conceptually revert #20276

   The feature was implemented for the `responders` gem. In the end,
   they did not need that feature, and have found a better fix (see
   plataformatec/responders#131).

   `ImplicitRender` is the place where Rails specifies our default
   policies for the case where the user did not explicitly tell us
   what to render, essentially describing a set of heuristics. If
   the gem (or the user) knows exactly what they want, they could
   just perform the correct `render` to avoid falling through to
   here, as `responders` did (the user called `respond_with`).

   Reverting the patch allows us to avoid exploding the complexity
   and defining “the fallback for a fallback” policies.

2. `respond_to` and templates are considered exhaustive enumerations

   If the user specified a list of formats/variants in a `respond_to`
   block, anything that is not explicitly included should result
   in an `UnknownFormat` error (which is then caught upstream to
   mean “406 Not Acceptable” by default). This is already how it
   works before this commit.

   Same goes for templates – if the user defined a set of templates
   (usually in the file system), that set is now considered exhaustive,
   which means that “missing” templates are considered `UnknownFormat`
   errors (406).

3. To keep API endpoints simple, the implicit render behavior for
   actions with no templates defined at all (regardless of formats,
   locales, variants, etc) are defaulted to “204 No Content”. This
   is a strictly narrower version of the feature landed in #19036 and
   #19377.

4. To avoid confusion when interacting in the browser, these actions
   will raise an `UnknownFormat` error for “interactive” requests
   instead. (The precise definition of “interactive” requests might
   change – the spirit here is to give helpful messages and avoid
   confusions.)

Closes #20666, #23062, #23077, #23564

[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]

- For old apps which are not setting any value for hsts[:subdomains],
  a deprecation warning will be shown saying that hsts[:subdomains] will
  be turned on by default in Rails 5.1. Currently it will be set to
  false for backward compatibility.
- Adjusted tests to reflect this change.

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

- We will reuse config.ssl_options for setting the HSTS settings.

1) Because if you forget to add Secure; to the session cookie, it will leak to http:// subdomain in some cases
2) Because http:// subdomain can Cookie Bomb/cookie force main domain or be used for phishing.

That's why *by default* it must include subdomains as it's much more common scenario. Very few websites *intend* to leave their blog.app.com working over http:// while having everything else encrypted. 

Yes, many developers forget to add subdomains=true by default, believe me :)

Only hijack Rack socket when first needed

Fix README heading according to Markdown conventions

Fixes #23471

The first heading in some README's are indicated using a second level
heading (`##`), which in my opinion is of incorrect structure.
Therefore, in this patch I changed the first heading to a first level
heading (`#`) in README's where this incorrect structure occurs.

[ci skip]

Enable ActionCable routes by default

This also marks Action Cable routes as internal to Rails.

Added a test for generating Strong ETag

[ci skip] Need to mention debug_exception_response_format in the api_app documentation.