Add support for public:// and private:// takeover

We use this patch on a few projects. I don't recall all the history behind why. But what is left before this can land? Do we need to add an update hook to refresh s3fs metdata cache?

I'm not actually using s3fs_cors on any sites at the moment so it would be much better to draw from others experiences on that portion to be sure no errors exist (I would suggest your own deployment is likely sufficient.)

Adding the hook is an option. Personally though I'm a bit hesitant to suggest doing a full S3fsService::refreshCache() as that can take from minutes to hours depending on the status of the bucket. That would leave the option of directly modifying the s3fs_file database table or using the s3fs_file table as a source of info to populate calls to S3fsService::writeTemporaryMetadata() (along with the other calls needed to setup the temporary metadata table.) During both of those the sites should ideally be in maintenance mode with no new file creation permitted to avoid any new writes being out of sync with the s3fs_file table.

Technically per the README sites never should have used s3fs_cors for public:// or private:// however we know they were. Ultimately adding the hook I think is a question of how user friendly should this be for sites that didn't read the README, or did but latter accidentally deployed an unsupported deployment and how much inconvenience (if we do a full cache refresh) we cause for sites that may have always followed the README.

Sadly this only worked because of bugs that existed in the s3fs module ignoring the s3fs_file cache table, otherwise it likely would not have made it into production deployments.

Re-roll

There's already a UI option to refresh the metadata cache, so I think it's fine to leave that to sites to do themselves.

I keep putting this off in fear this will break some poor unsuspecting site. But I'm going to take the plunge and commit these changes. If someone's metadata cache goes wonky, they can refresh the case via the UI.

Automatically closed - issue fixed for 2 weeks with no activity.