Don't break use-context shared-gdrive if a file is renamed

[asolove]

@schanzer reports:

When loading a context via shared-gdrive, for some reason the fileID and fileName are required. If the filename of the file being loaded changes, it breaks every program that loads it! This is a maintenance nightmare. Would it be possible to just check the name of the file when it loads, and update the string accordingly?

AFAICT from debugging this, we only need the id to fetch the contents of the file from a security/permissions standpoint. Even if I change the file name to be wrong, the contents of the file are fetched by id and make it all the way to the browser. We're just choosing to throw an error after that if the name doesn't match.

From a cursory look, this seems not hard to fix. But before I attempt a fix, I am filing this issue so someone has a chance to tell me this is a load-bearing error or if there is some history as to why the name match is enforced.

[blerner]

IIRC, it was because we mostly didn't trust students/teachers to copy that fileID correctly, and wanted a belt-and-suspenders check to make sure we were retrieving the intended file. We definitely want to keep the fileName in the syntax, since a file with several import shared-gdrive("<gibberishID>") lines is a maintenance nightmare. I don't think the file name is "load-bearing", in the sense of "if it doesn't match, Pyret cannot work right", but it's not deadweight, either.

[blerner]

I do wonder if the history of file renamings is persisted with the file? So e.g. if the fielIDs match and the fileName matches some name in the history of the file?

[schanzer]

@blerner it doesn't look like we can retrieve the previous filenames, as the docs for the revision structure only include the original filename.

Proposal:

If the name doesn't match but the ID does, put up a dialog notifying the user and asking if this really is the file they wanted. If it is, change the string on line 1 of the file to match whatever the updated name was, to prevent the warning from re-appearing. We could even supply the original name as a hint.

[blerner]

Fine, then just check the original filename. That's the likeliest one to matter, anyway. I was worried we wouldn't have access to any prior names...

We don't currently have any dialogs or warnings in pyret: things either work or are compilation errors. I don't think this is urgent enough to warrant a new modality of warning messages, but it's possible we need to improve what the compilation error looks like. (I'm on my phone right now, not computer, so I can't see what the current error looks like...)

[asolove]

Hmm, I don't think just checking the original filename will work thoroughly. (Imagine the case where the imported file is renamed once, and the importing program is updated to use the new filename, but then the file is renamed a second time. Now the importing program has an intermediate name and we can't detect it is reasonable.)

FWIW here is the current message. Note that it does include the new file name, but could be more explicit that you can just change your code to use that name and it will work: