feat(audit-server): build server-side logic for log period deletion keys

[ncdiehl11]

Overview

Introduces audit-server-side logic for creating and storing unique deletion keys for each successful log download request at /audit/external/logPeriods/${logPeriodId}/download. Deletion keys do not survive server restarts.

Closes EXEC-2878

Test Plan and Hands on Testing

• push audit-server to a CRS bot, and make a request to download a log period
• inspect the response and look for the deletion token in the headers

Changelog

• add deletion key attribute and creation fn to LogDataManager
• wire up deletion key creation in log export router
• pass deletion key back in the headers of the above response
• add unit tests

Review requests

Please inspect code and unit tests.

Risk assessment

low

[sfoster1]

i don't think the deletion key needs to go in the database at all, honestly. the reason this exists is to provide a "hey wait!" warning flag if somebody writes a client that just deletes stuff without thinking about it, and for that purpose having them live in memory (with some limit - one per period, even) is totally fine. there's no need for them to survive reboots.

[ncdiehl11]

i don't think the deletion key needs to go in the database at all, honestly. the reason this exists is to provide a "hey wait!" warning flag if somebody writes a client that just deletes stuff without thinking about it, and for that purpose having them live in memory (with some limit - one per period, even) is totally fine. there's no need for them to survive reboots.

So do you propose this logic lives purely in Redux state? The flow in this case would be:

• client requests raw log data
• server sends back a unique deletion key in the headers of a successful response and stores on the log data manager
• client stores that deletion key linked to the log period for which the download request was made