Avoid suggesting very unlikely changes in rails app:update - #41083

Currently when you make a new Rails app, we generate a lot of initializers. For new users, I think we should try and include as few as possible - the less files, the less daunting a new app is. And for upgrades I'd like to [continue to simplify the update process](rails#41083), in this case by not bringing back initializers you have probably already dismissed or modified.

In this PR I'm proposing we remove two initializers: `application_controller_renderer.rb` and `cookies_serializer.rb`:

**`application_controller_renderer.rb`**. This configures [`ActionController::Renderer`](https://api.rubyonrails.org/classes/ActionController/Renderer.html), for rendering views outside of controller actions. I don't think this is something most Rails apps will need (certainly not on day 1); users can configure this feature when they need it.

**`cookies_serializer.rb`**. This was added for [Rails 4.1](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#cookies-serializer). The behaviour is:

- For new apps, the initializer says `:json`.
- For upgraded apps that don't have the initializer, it is added with value `:marshal`.
- If there's no initializer, the [default value](https://github.com/rails/rails/blob/c9a89a4067834a095a41084030b8c9ccdbce77d5/actionpack/lib/action_dispatch/middleware/cookies.rb#L589) is `:marshal`.

Since nobody should be upgrading direct from Rails 4.0 to Rails 7.0, we can simplify this by using new framework defaults. So the behavior will now be:

- For new apps, `config.load_defaults("7.0")` sets the value to `:json`.
- The `new_framework_defaults_7_0.rb` file explains this, and suggests using `:hybrid` to be upgrade to JSON cookies.
- No changes to [the code](https://github.com/rails/rails/blob/c9a89a4067834a095a41084030b8c9ccdbce77d5/actionpack/lib/action_dispatch/middleware/cookies.rb#L589); the default value is `:marshal` if you don't set one.

So if you were not setting a `cookies_serializer` previously and you want to keep using `:marshal`, you'll need to explicitly set this before using `config.load_defaults("7.0")`, otherwise it will switch to `:json`. The upside of this is you won't get the `cookies_serializer.rb` file created for you every time you upgrade.

Currently when you make a new Rails app, we generate a lot of initializers. For new users, I think we should try and include as few as possible - the less files, the less daunting a new app is. And for upgrades I'd like to [continue to simplify the update process](rails/rails#41083), in this case by not bringing back initializers you have probably already dismissed or modified.

In this PR I'm proposing we remove two initializers: `application_controller_renderer.rb` and `cookies_serializer.rb`:

**`application_controller_renderer.rb`**. This configures [`ActionController::Renderer`](https://api.rubyonrails.org/classes/ActionController/Renderer.html), for rendering views outside of controller actions. I don't think this is something most Rails apps will need (certainly not on day 1); users can configure this feature when they need it.

**`cookies_serializer.rb`**. This was added for [Rails 4.1](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#cookies-serializer). The behaviour is:

- For new apps, the initializer says `:json`.
- For upgraded apps that don't have the initializer, it is added with value `:marshal`.
- If there's no initializer, the [default value](https://github.com/rails/rails/blob/c9a89a4067834a095a41084030b8c9ccdbce77d5/actionpack/lib/action_dispatch/middleware/cookies.rb#L589) is `:marshal`.

Since nobody should be upgrading direct from Rails 4.0 to Rails 7.0, we can simplify this by using new framework defaults. So the behavior will now be:

- For new apps, `config.load_defaults("7.0")` sets the value to `:json`.
- The `new_framework_defaults_7_0.rb` file explains this, and suggests using `:hybrid` to be upgrade to JSON cookies.
- No changes to [the code](https://github.com/rails/rails/blob/c9a89a4067834a095a41084030b8c9ccdbce77d5/actionpack/lib/action_dispatch/middleware/cookies.rb#L589); the default value is `:marshal` if you don't set one.

So if you were not setting a `cookies_serializer` previously and you want to keep using `:marshal`, you'll need to explicitly set this before using `config.load_defaults("7.0")`, otherwise it will switch to `:json`. The upside of this is you won't get the `cookies_serializer.rb` file created for you every time you upgrade.

This is a partial revert of rails#41083.

Rails has improved `puma.rb` sometimes, for example, 06d614a
and f719787.

To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.

This is a partial revert of rails#41083.

`puma.rb` may update by users, but  Rails has improved `puma.rb` sometimes.
For example, 06d614a and f719787.

To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.

This is a partial revert of rails#41083.

`puma.rb` may update by users, but  Rails has improved `puma.rb` sometimes.
For example, 06d614a and f719787.

To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.

This is a partial revert of rails#41083.

`puma.rb` may update by users, but  Rails has improved `puma.rb` sometimes.
For example, 06d614a and f719787.

To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.