Record file attachment names separately from file itself

[legoktm]

Description

One of the limitations in SecureDrop Client/App is that we have zero information aside from file size about a file until after it's downloaded. (Even the file size is a bit of a lie, it's the encrypted file size...)

Similar to #7494, we could record the file name (and maybe mime type?), encrypt it and save it. Then the Client/App can download it as part of sync, so we can display it to the user so they have some details before they start the download.

(No expectation this will ever be implemented in the current server, but would be good to keep in mind for the protocol, that we should store/transmit file metadata cheaply and independently of the file itself)

[vickiniu]

@legoktm relatedly, I noticed that we include filename in the v1 API response, and as part of the work on implementing download + decrypt was going to propose that we add filename to the v2 API response and include it in the sync metadata: https://github.com/freedomofpress/securedrop/blob/develop/securedrop/models.py#L323

this would save us from having to first make a request to the v1 API to fetch metadata for a reply/submission, and then executing the actual download. I think that would accomplish at least a part of this, in being able to display the filename to the user. it looks like the v1 API also includes size, so not sure if that would also be feasible or something we'd want to add to the v2 API response to also include as part of metadata sync

[legoktm]

@legoktm relatedly, I noticed that we include filename in the v1 API response, and as part of the work on implementing download + decrypt was going to propose that we add filename to the v2 API response and include it in the sync metadata: https://github.com/freedomofpress/securedrop/blob/develop/securedrop/models.py#L323

This is the encrypted filename, which is something like 4-fashioned_account-doc.gz.gpg. We don't actually need it, since when we download, we can use use something deterministic instead, like {source_uuid}/{file_uuid}/encrypted.gpg.

Part of the reason we intentionally removed the filename from the v2 API is because in the past we messed up and didn't validate the server-provided filename, opening us up to path traversal attacks (GHSA-6c3p-chq6-q3j2). So I think every step of the way the app should create/use its own filenames, until the very end when the file has been decrypted, when we want to use the source-provided filename with some validation ({source_uuid}/{file_uuid}/{source_provided_file_name}?).