Figure out join() and Drop behavior for DownloadHandle

[graebm]

Currently, DownloadHandle has a join() function, but neither cp.rs or the benchmark runner bother to call it. It was added because UploadHandle has a join(), and we thought the APIs should be similar.

But DownloadHandle::join() cancels the download, while UploadHandle::join() waits for the upload to successfully complete, and has a separate UploadHandle::abort() function. Should we rename DownloadHandle::join() to DownloadHandle::abort()?

Also, what's the Drop behavior for DownloadHandle? We should probably ensure its spawned tasks get cancelled ASAP. Likewise for UploadHandle/UploadObjectsHandle/DownloadObjectsHandle

• Drop and cancel for UploadHandle/UploadObjectsHandle (PR)
• Drop and cancel for DownloadHandle (PR)
• Drop and cancel for DownloadObjectsHandle (PR)

[ysaito1001]

This issue can be closed once all subtasks have been completed. As a result of the subtasks, here is a summary:

---	Join	Abort	Drop
DownloadHandle	there is no join, but drainconsumes the body	cancels in-progress tasks ASAP but gracefully	futures for in-progress tasks are destroyed at whatever await points
UploadHandle	waits for completion of spawned tasks	ditto	ditto
DownloadObjectsHandle	waits for completion of spawned tasks	ditto	ditto
UploadObjectsHandle	waits for completion of spawned tasks	ditto	ditto