FR: ACL for Parse.File

Currently, to access a file, you only need the URL. Once someone has the file URL, it's there's forever. Although the file names are long random strings, some deeper security might be required for certain files.

I'm working on a PR that could hopefully help manage Parse.Files a bit better, which could work towards keeping track of file reference counts and "cleaning up" files with no references. I've also worked on some other features:

This PR, creates a "_File" object on the save of a file, which generates an OTP secret. The OTP secret is then used to create a token when a Parse.Object with a Parse.File is requested (providing the auth is valid for the "_File" acl).

The file url will now have a token attached to it, which expires in 5 min, meaning that the GET request can be performed, but the URL won't be able to pull the file later (unless ACL is set to public read).

I added 'references' to the '_File' object, and I was thinking when a Parse.Object is saved referencing a file, increment 'references', and when it changes or removes the file, decrement 'references'. Then, if 'references' == 0, delete the file.

I've currently passed the ACL through setTags (for proof of concept) as there's no setACL on Parse.File yet.

I'm also not sure how running .save on an existing file would affect this (E.g changing data or changing ACLs. Maybe I should query "_File" first?).

I've started working on a draft PR as to how I imagine this feature being implemented. Any thoughts or suggestions are valued.

This is in relation to #6572, #5080, #1023, #6780 and this discussion in the community forum.

Start by reviewing draft PR #7000 and the related issues #6572, #5080, #1023, and #6780, along with the linked community discussion. Focus on the proposed _File ACL, expiring file URL tokens, and reference counting, including the unresolved behavior for existing files and ACL changes. Done requires an agreed implementation scope rather than the current proof of concept.