Add getFilesystem method to CacheStorage

[rvanlaak]

Just like the OriginalStorage exposes storage. Without this change it does not seem possible to generate temporaryUrls for S3 buckets.

Relates to #75 , so adding temporary url generation and not exposing filesystem is fine by me as well.

Workaround for now; wire the same Flysystem filesystem to my own action until this PR becomes available or temporary url generation is integrated.

[xavierlacot]

Hi @rvanlaak

Thanks for the patch! You're right that the asymmetry between OriginalStorage and CacheStorage isn't intentional, so exposing the filesystem here is fine.

Just be aware that cache entries are generated lazily: calling temporaryUrl() on a variation that hasn't been stored yet will produce a valid signed URL pointing at a missing object. You'll want to make sure the variation exists first.

Also, note that CacheStorage::store() writes with visibility: public, so depending on your bucket policy a plain publicUrl() may be enough for variations. Presigned URLs are mostly useful for originals. What's your setup there?

I would rather like #75 to land a proper getTemporaryUrl() on both storages, so the path resolution and the lazy generation are handled by the bundle rather than by each application. What do you think of it?

[rvanlaak]

Pinned down a performance issue last week on resolving the S3's temporary urls for the variations, so the way how temporary URLs for both the original and cache storage are accessible could use some enhancement. What happened was that a 'manager' class was resolving the S3 URLs - involving checking whether the file exists on the bucket. This should not have happened on GET endpoints. For variations it should be simpler to rely on their existence (or have a hook to dispatch a bg job to check and create them?).