Only de-dup/cache FileSystemResolvers in ViewPaths

[jhawthorn]

Fixes #47449

Previously I attempted to de-dup and cache any FileSystemResolver under the same path. This created issues because each Resolver caches its templates. Those cached templates only get compiled once into whatever compiled_method_container is passed on its first render. So separate compiled_method_containers must have different copies of a Template, and therefore separate copies of each Resolvers.

I tried a few approaches where I would have a separate cache of resolvers per-compiled-method-container, but I wasn't really successful as in most of the places we performed the casting we did not know or have access to the view context class and therefore compiled method container (it isn't stored in the LookupContext or ViewPath) and trying to add that relating created incompatibilities in some not-quite-public-but-still-widely used APIs for using ActionView directly.

This approach instead limits where we perform the de-dup and cache, to only descendants of ActionView::ViewPaths. These can be assumed to also inherit from ActionView::Rendering (I think ActionController::API is an exception here, which should be addressed in a future refactor) which means that they should all share the same compiled_method_container and therefore can all be cached safely together.

This should continue to ensure we don't leak memory from {append,prepend}_view_path at runtime, while maintaining compatibility with some of the more specialized uses of ActionView::Base as a standalone API. However this leaves open the possibility (which has always existed) of using that standalone API in a "leaky" way.

[jhawthorn]

@rafaelfranca updated this to avoid as many rebuilds of the watcher as possible. Hopefully that addresses the performance regression you saw.

[rafaelfranca]

I'm not sure I got how this decrease the number of times the file watcher is initialized when a new engine path is added. prepend_view_path is always called with an array of strings, and if I got this code correctly, cast_file_system_resolvers would still be called for each one of engines. Am I missing some other cache layer?

[jhawthorn]

I see. I was hoping that your view paths would be appended as an array. I suppose that doesn't block this (as it fixes the other issue) but may not solve the regression you saw.

[rafaelfranca]

The view paths are appended by this code here

rails/railties/lib/rails/engine.rb

Lines 603 to 609 in 64ad045

	initializer :add_view_paths do
	views = paths["app/views"].existent
	unless views.empty?
	ActiveSupport.on_load(:action_controller) { prepend_view_path(views) if respond_to?(:prepend_view_path) }
	ActiveSupport.on_load(:action_mailer) { prepend_view_path(views) }
	end
	end

That doesn't block this fix for sure.