it's the max that a single part direct upload can be (as coded), and the
minimum part size for multipart uploads.
These could be separate settings, but it's not clear that that's useful
to support. E.g. for AWS S3, the min-part-size is 5MB but single uploads
could go to 5 GB so that is the max single upload.

at one point I was sending parts that were below the min-part-size on
AWS and everything worked until a 400 response/Entity too small response
when trying to complete. This commit would try to clean up after any
similar problems (as the code now stops this aprticular one from
happening).

add release note

…tyConsortium/dataverse.git into IQSS/6763

Conflicts:
	src/main/java/edu/harvard/iq/dataverse/LoginPage.java

where the dataset.getId() is null

when no mimetype is assigned by the browser

Conflicts:
	src/main/webapp/editFilesFragment.xhtml

Conflicts:
	src/main/java/edu/harvard/iq/dataverse/util/FileUtil.java

Conflicts:
	src/main/java/edu/harvard/iq/dataverse/EditDatafilesPage.java
	src/main/java/edu/harvard/iq/dataverse/api/Datasets.java
	src/main/java/edu/harvard/iq/dataverse/dataaccess/S3AccessIO.java

still want to trigger the retry or report the error in this case. Prior
code assumed the last call to finish succeeded.

for cancel - catching the per datafile cancel button and handling the
abort, after all currently uploading parts are done, in mp calls, to
remove the file

Note for single part uploads, cancelling the file does not yet remove
the temp file, but in that case we do add the temp label so files can be
cleaned up later. (Todo note includes more info)