Fix incorrect cache usage by available_properties (big cache use, slo…

[mrbrdo]

…w reads)

Spree::Filters::PropertyPresenter includes all ProductProperty for all Products, which can be very many. This would be serialized and stored in the cache by Rails.cache.fetch. As only uniq_values are actually relevant and being used, all the ProductProperty's should not be stored in cache. The number of these properties can be very significant (in the 1000s), taking up a lot of cache and making the cache read very slow (over 1 second with solid_cache).

This fixes two issues, which were for me quite big:

• very bad performance on reading the property filters from cache, which can actually be slower than the queries themselves (in my case I have observed 1.5s just for the cache read)
• incredibly high cache space use due to storing many unneeded records in the cache - due to web crawlers, I've actually had 100GB of disk filled with fragment caches within a day or two (there might be other culprits, but this one surely contributed)

@damianlegawiec I'm not sure how this is handled with api v2, but you might want to check in case you use cache there. PropertyPresenter is not designed well to be cached directly, as it was being used now.

The solution could be better by redesigning Spree::Filters::PropertiesPresenter/PropertyPresenter, but I didn't want to fiddle too much with the core gem in this case.
I think the same issue could be there with OptionsPresenter, but I didn't have time to check that right now.
Also I think these available-properties cache entries are being created for product searches as well (each search term with its own cache key), which is probably a bad idea as it will eat up the cache space very quickly as well and the usefulness of that is very limited.