Migrate Libs To Rely on get_file_contents Rather Than Presigned S3 URLs

[indiv0]

Currently, it is possible to fetch an organization's files directly from S3 via the presigned URLs supplied by the cloud backend. These URLs are being deprecated as we are moving to SSE-C encryption for all user-supplied objects for compliance/security reasons. Presigned URLs are not easily compatible with SSE-C encryption since encryption key headers must be added to the presigned URL prior to use. We do not wish to expose SSE-C encryption keys to users, so we have added a get_file_contents lambda that proxies requests to fetch a file. This lambda adds the necessary headers and decrypts the file prior to returning it to the user.

For the relevant changes on the cloud backend:

Making requests to the new lambda:

https://github.com/enso-org/cloud-v2/blob/dc8a66281770623e1b32caa1ec3a2c0f7d3cf4da/src/lambdas/src/lambdas/files/endpoints/get_contents.rs#L37-L50

url field removed from this response body:

https://github.com/enso-org/cloud-v2/blob/dc8a66281770623e1b32caa1ec3a2c0f7d3cf4da/src/lambdas/src/lambdas/files/endpoints/get_details.rs#L66-L69

path field removed from this response body:

https://github.com/enso-org/cloud-v2/blob/dc8a66281770623e1b32caa1ec3a2c0f7d3cf4da/src/lambdas/src/lambdas/files/endpoints/upload.rs#L91-L95

It is now up to the client to construct the appropriate URL from the file_id, and requests to the new lambda must provide the JWT token for the requests to be authorized.

NOTE: To make this migration non-breaking, it is being done in two stages. First, the get_file_contents lambda with the new functionality is being added (while files are still unencrypted). This change is already deployed. Once the libs have been migrated to use the new endpoint, enso/cloud-v2#1316 will be deployed, which encrypts all the files and removes the deprecated fields from the responses.