Updating tickets (#421, #488, #520, #572, #617, #618, #623, #628, #629, #630, #631, #641, #645, #648, #654, #657)

The current semantics for a guest-upload-voucher is that it can be used to upload one file. This needs to work at the same time as "pause/resume" needs to work.

After todays conference call the following solution was proposed: A guest-upload-voucher does not use the FileUID field. We will use this FileUID field to link a guest-upload-voucher to a pending-upload-entry. That way we can recognise an upload voucher is already in use, when dealing with a pause/resume situation, a new upload is started in a separate tab etc.

This will be combined with two checks:
-before upload check whether the file-to-upload already is being uploaded (=present in the pending entries): ticket #663
-after upload check whether the filesize on the server is the same as filesize of file when sent (crude checksum): ticket 629

When uploading using a guest-upload-voucher the following happens:

-User logs on with voucher
-Starts upload
-Pending entry is created in database
-Voucher entry updated with FileUID containing pending_entry_ID (stored in
filevoucheruid for pending entries)

On complete, the voucher is closed, the pending entry is moved to a "uploaded" state

If an attemptis made to use a voucher with an existing value in FileUID, it will be a resume (if pending_entry_id is the same) or undesired use (trying to upload the same file twice) or use that does not comply with current guest-voucher semantics: multiple transactions with the same guest-voucher.

Upload of same file twice at same time will result in a corrupt file on the server. By checking the filesize on receipt (see ticket #629) we can display an error "Something went wrong, the file is a different size..., did you maybe upload the same file in multiple browser windows?"

Once this solution is implemented we need to do the multiple-uploads mutliple-tabs check again.

Note that we will probably have to revisit this solution when implementing multiple-file-in-one-transaction upload

After 1 week of fix attempts it turns out this requires more changes to code than we're willing to do at the moment (might risk delays in 1.5 shipping). Given that the problem is already there in FileSender 1.1, vouchers are used but not that often, this is a corner case and a filesize check in the end provides a crude anticorruption check, this one will be postponed until after 1.5 most likely.

It's not unlikely we'll fold this one in the work to be done for implementing multiple files.

Chris wil upload current attempts at fixing this into playground directories in SVN.