Introduced in e56c6354, `CacheHelper#fragment_cache_key` is a duplicate of `ActionController::Caching::Fragments#fragment_cache_key`.

We now require the view to provide this method on its own (as with `view_cache_dependencies`); `ActionController::Caching::Fragments` exports its version as a `helper_method`.

This commit fixes the bug convering `false` to `locals[as]` when
`options[:object]` is `false` (close #22260).

Adds the `virtual_path` option to `cache_fragment_name` so it can
be provided when needed.

That allows `cache_collection_render` to get the appropriate cache
key with the digest generated based on the template and prevent
collision with other templates that cache the same collection.

When one rendered a partial template without specifying an object
or a collection (e.g. <%= render partial: 'partial_name' %>), Rails
would make an object called :partial_name available in local_assigns.
I don't think this was the intended behavior, since no local variable
called 'partial_name' gets defined in the view.

Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.

The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.

So with a notifications/_notification.html.erb template like:

```ruby
<% cache notification %>
  <%# ... %>
<% end %>
```

A collection would be able to use `multi_read` if rendered like:

```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```

The testing of error messages have been implemented wrongly a few times.
This is an attempt to fix it.

For example, some of these test should have failed with the new code.
The reason they are not failling with the new string is the fact they
were not being tested beforehand.

Makes caching a collection of template partials faster using `read_multi`
on the Rails cache store.

Some caching implementations have optimized `read_multi` so we don't have
to check in the cache store for every template.

because the partial renderer would not create an lvar per each template since c67005f2

before this PR IDENTIFIER_ERROR_MESSAGE could lead to misunderstand the convention of partial name.
Added OPTION_AS_ERROR_MESSAGE for unvalid charter in as option.

The iteration object is available as the local variable
"template_name_iteration" when rendering partials with collections.

It gives access to the +size+ of the collection beeing iterated over,
the current +index+ and two convinicence methods +first?+ and +last?+

"template_name_counter" variable is kept but is deprecated.

[Joel Junström + Lucas Uyezu]

Just so it's clearer what's going on in the following assertion.

/cc #11993 @robin850

This test were assuming that the list of render options will always be
the same. Fixing that so this doesn't break when we add/remove render
option in the future.

automatically call @foo.to_partial_path

Calling `render @foo` allows local variables but not options to be
passed to the partial renderer. The correct way to render an object AND
pass options to the partial renderer is to pass the object in the
`:partial` parameter. However, there were previously no tests for this
behaviour (in `render_helper_test.rb` at least).

Missing partial folder/_partial instead of folder/partial.

Closes #13002.

This makes the test compatible with other Ruby implementations, which
may implement error messages differently.

Same as 4d4ff531

Fix default rendered format problem when calling render method without :content_type option. Closes #11393.

Now if somebody by mistake will remove malformed files test will raise error.

+use_full_path+ option was removed in 3b3790a4 and passing the template
handler to render was deprecated in 43d27e91.

Introduced in 2c22376f

Previously rendering a partial without giving :object or :collection
would generate a local variable with the partial name by default.

This was noticed due to warnings in Ruby 2.0 of not used variables,
which turned out to be the generation of not used variables inside
partials that do not contain objects related to them.

This handler simply allows arbitrary Ruby code as a template

Fixes #2394