Submissions endpoint stores additional metadata

[jack-h-wang]

User Story

As a sender onboarded to ReportStream, I want all data associated with my submission to be handled as expected.

Description/Use Case

Senders using the submission endpoint may include optional metadata in their submission, such as a payloadname. The reports/waters API currently populates the receive step with this metadata, and it is possible to look it up at any point in the pipeline by tracing back to the report tied to receive. As of #16409 the convert step will be recognized as the root report for submissions originating from the submissions endpoint, and this metadata will not be present. This metadata needs to be preserved and retrievable in a manner similar to how it is currently handled by the UP receive step.

Risks/Impacts/Considerations

Dev Notes

• This is largely needed for the sendOriginal feature, which needs to retrieve the submission file as it was received, as well as a payloadname if one was provided by the sender. The original design of the feature is that the translate step retrieves the root report (assuming it will be receive) to obtain this information. If the receive step is no longer the root report, an alternate means of storing this information and for the translate step to retrieve it is needed. See the documentation for this feature.
• The convert step is not an ideal or logical location for storing this metadata, but it is possible to use it in this manner; the original bodyURL can likely be retrieved from action_params and there is no currently known use for the external_name database column for this step.

Acceptance Criteria

• Submissions originating from the submissions endpoint have any sender-supplied metadata stored.
• Confirm sendOriginal is still able to retrieve a sender-supplied payload name when using the submissions endpoint.
• Confirm sendOriginal is still able to retrieve the original submission blob when using the submissions endpoint.

[jack-h-wang]

The work specified in this ticket is completed by #16723.