Add cache_key_method configuration option

[Flixt]

Hi there,

we have the case currently, that the hard coded call to cacheable.cache_key in the Plan is not outdating our cache when we update a model. The reason is, that the Model#cache_key value does not change after the model is updated, which is correct behavior for Rails >= 5.2 since the cache_key method should be used to for "recyclable" cache keys.

Cache versioning is disabled by default for Rails 5.2, >= 6.0 (ActiveRecord::Base.cache_versioning = false). Cache versioning is enabled by default for Rails >= 6.0 (ActiveRecord::Base.cache_versioning = true).

See https://api.rubyonrails.org/v5.2/classes/ActiveRecord/Integration.html#method-i-cache_key

I opened this PR for a few reasons instead of just overwriting cache_key on my models:

• I would have to overwrite it for every model or in the base model, which is probably a bad idea for existing applications, that use caching in other cases than serializing models (e.g. rendering views).
• I would loose the recyclable cache_key that I'll probably need in another place.
• I think it would be a good thing to be able to change the CacheCrispies default from cache_key to cache_key_with_version in a future major release.

I had several other solutions in mind to solve this "problem".

• A serializer specific cache_key class method, that would enable us to configure the used cache_key per serializer.
• Extending the serializer specific addons to also get model instance passed into the block.

I did not choose them because from my point of view they have one major draw back, that is: They are hard to reason about in an inheritance chain of serializers (which I think is even with a simple setup, at least 3 classes deep, MySerializer < MyBaseSerializer < CacheCrispies::Base). It is not really clear if such a configuration would be inherited or not.

I also did not chose to extend the addons block feature because it takes a single positional argument currently (options) and passing it the model as second positional parameter would not be consistent with the rest of the API (show_if etc..). Would be a little challenge to make this change backwards compatible and consistent with the current api (probably something to consider for a major release?).

Another reason is, I don't think it is neither necessary nor a good thing to animate developers to use different methods on different models to generate the CacheCrispies cacheable.cache_key. With the chosen solution it would be possible to enhance it to support a Proc as the cache_key_method that is called and gets passed the options and the model instance.

[diazweb]

Hey! This PR its important to make the cache work on rails 6.X, good job @Flixt

Have you give a look into this @adamcrown?

[adamcrown]

This looks great. Thanks Felix!