Is your feature improvement request related to a problem? Please describe.
Currently the file transfer service accepts the raw bytes of the file as the body for a request to upload a file with no means to verify the upload is complete. This means that if the connection is interrupted, e.g. the uploading device loses network connectivity, the payload abruptly stops. Since there is no means for us to detect this interruption, the partial upload is persisted as if it was completely successful.

Describe the solution you'd like
The file-transfer service should optionally accept a Content-Length header and use this to verify the entire file has been received if this header is provided. thin-edge internal use of the file transfer service should all be updated to provide this header if it isn't already.

This would be very easy to implement as a backwards-compatible change, and the improvement could be easily used with curl --upload-file {filename} localhost:8000/tedge/file-transfer/{targetpath}.

Describe alternatives you've considered
Accepting multipart/form-data would also achieve the same result of ensuring the file is uploaded successfully, but is less convenient to use. It would also increase the payload size due to base64 encoding the body. The features of multipart encoding which make it a good fit for uploading multiple files/uploading a file along with supplemental data wouldn't be of value to the file transfer service and would just add to potential sources of confusion. Additionally if a user attempts to upload a multipart/form-data body without supplying the accompanying Content-Type header, the upload would succeed rather than providing an error.

Additional context