Support resuming of aborted uploads during `vm publish`

[AliSoftware]

Quick implementation of a resume mechanism for hostmgr vm publish.

Closes https://github.com/Automattic/hostmgr/issues/86

Note: This PR sits on top of https://github.com/Automattic/hostmgr/pull/88 and targets the vm-list-cleanup branch, to avoid conflicts while working on those different features of the codebase.

How it works

• When we ask tinys3 to start a (multipart) upload, instead of immediately issuing a CreateMultipartUploadRequest, it first checks if there is an existing ListMultipartUploadRequest matching the destination (key) to which we want to upload.
• If it finds at least one, it picks the most recent of those uncompleted uploads for this key, then uses ListPartsRequest to fetch all the parts already uploaded for that multipart upload request. If it doesn't find one, then it initiates a CreateMultipartUploadRequest as before
• When calling uploadPart, we now also pass the existing AWSUploadedPart candidate, if one exists (i.e. if a previous upload was found and that part index was present in it). This is then used to check if the ETags/MD5 checksums of the existing candidate still matches the md5 of the part we're about to upload, and if so, skip the upload of that already-uploaded part.

[AliSoftware]

I ran it locally and there's no indication from the logs that we're resuming, so I wonder if we'd be able to tell if it weren't?

Yeah I considered adding logs, then realized that from within tinys3 library we're not really supposed to print into STDOUT (i.e. every reporting is done via the progressCallback, and the caller of tinys3 (<- libhostmgr <- hostmgr CLI) are the ones providing the entry points into the Terminal output…

So while I initially added a print there, I figured the right way to do it would instead be to provide some logCallback entry point in tinys3 then libhostmgr that would be fed and provided by the hostmgr client / executable. This can certainly be done, but was adding a lot of cruft to the various API layers for little benefit, so I figured it wasn't worth it just for that simple log info.

---

PS: Besides, since parts are uploaded in parallel, and thus it can be possible that when the upload got interrupted only part 2 and 3 were uploaded but not part 1 for example, that means that during resume the progress would start and upload part 1, calling progressCallback and printing the new % values to the terminal… and then in the middle of it we'd print some logs in a new line about parts 2 and 3; meaning that the ProgressBar would then resume counting % on the line after (if not overriding the log, depending on \n vs \r…). Not the end of the world, but would make the ProgressBar output in the Terminal look a big ugly due to being interrupted by those logs randomly 🤔

[AliSoftware]

I ran it locally and there's no indication from the logs that we're resuming, so I wonder if we'd be able to tell if it weren't?

btw FWIW the way I tested this was:

• Run hostmgr vm publish xcode-15.3-v3 in one Terminal tab
• Run aws s3api list-parts --bucket a8c-macos-ci-images --upload-id {value} --key images/xcode-15.3-v3.vmtemplate.aar in a separate tab regularly, and note how new parts started to appear for that uploadId
• Interrupt hostmgr vm publish after a while (≈ 60%)
• Run hostmgr vm publish again, and see the progress speed up very quickly at the start
• See aws s3api list-parts listing continuing to see new parts and grow from where things were left off, and with previously uploaded parts still having their initiatedDate matching the date from the first vm publish, not the second attempt
• Once upload was finished, re-downloaded the whole object using aws s3 cp s3://a8c-macos-ci-images/images/xcode-15.3-v3.vmtemplate.aar ~/Desktop then ran shasum on it, and compared it with the shasum of /opt/ci/vm-images/xcode-15.3-v3.vmtemplate.aar and confirmed they matched too.