checkOnDeferredUploads: Did not have deferredUploadId

[crspybits]

I'm getting this in logs from Dany--

2021-06-20 11:46:34.644 [Error] [main] [ServerInterface.swift:126] userEvent(_:event:) > Optional(iOSBasics.SyncServerError.internalError("synchronouslyRun: [iOSBasics.SyncServerError.internalError("checkOnDeferredUploads: Did not have deferredUploadId.")]"))

This is from iOSBasics and in result, a cleanupAfterVNUploadCompleted doesn't happen.

I could attempt to get the deferredUploadId from the server again, but I plan to remove these rows from the server eventually-- see SyncServerII/ServerMain#10. So, if the row had been removed, what would happen then?

It seems safer to just re-do the upload.

However, a simple means of this is to just reset the upload tracker in iOSBasics to .notStarted. However, the context in which this Did not have deferredUploadId issue is occurring is an iOSBasics checkOnDeferredUploads(). And we have two possible states:

1. If the deferred uploads have not completed, then the Uploads records for the upload batch will not have been removed.

2. If the deferred uploads have completed, then the Uploads records for the upload batch will have been removed.

I think the way to deal with this is to:

A. Attempt to get the deferredUploadId from the server. It turns out that there is currently not enough information in the DeferredUpload table in order for the client to just retrieve the deferredUploadId independently from that table.

B. Only if that fails in a positive manner, i.e., with an indication that the row doesn't exists (not with a generic other error such as a network error), re-do the entire upload again-- not just for the single file, but for all files in the object upload.

Actions:

Action0: Add a fallback to iOSBasics to deal with B. above.

Action1: Add a batchUUID field to the DeferredUpload table. This will enable a client to be able to get the deferred uploads result with the deferredUploadId. This will not help Dany with his present situation, but should help this error in the future.

Action2: Allow the GetUploadsResults endpoint to operate with either the batchUUID or the deferredUploadId or both.

Action3: In iOSBasics, don't throw an error if the deferredUploadId is absent. Pass the batchUUID along also to the GetUploadsResults.

Action4: Add server tests to make sure that GetUploadsResults can operate with the batchUUID alone or with both batchUUID and deferredUploadId.