Store provided identities in app database

[mfbrown]

Description

The DEFAULT_TTL_SECONDS setting clears out the PII which means that there will be "blank" rows in the Subject Request list page that make it look like the product is "broken. We should be storing the provided identity in a longer term storage location so that the PII doesn't get removed. This also will lend a hand in the future for other record-keeping and documentation requirements that are required by some regulation.

Breakdown PII types and storage location and how we should handle the PII

• initial identity: stored in the app DB alongside the privacy request (this allows us to search on it and provide context for history of the request); we should persist the provided identities for regulation's record keeping requirements and for a better user experience in the UI.
• traversal data: stored in the cache and SAR packet only ever (this is data from production datastores so should never be revealed anywhere); this is the type of data that we need to be the most careful with and should adhere to the DEFAULT_TTL_SECONDS setting
• account data: stored in the app DB and viewable in the interface freely (this is data pertaining to fidesops users, not identity data in production datastores); this type of data should be persisted and NOT adhere to the DEFAULT_TTL_SECONDS setting

Additional Context

• purely a BE ticket
• scope is only for the initial identity changes

Acceptance Criteria

1. Confirm that initial identity information will persist in the UI and not adhere to the DEFAULT_TTL_SECONDS setting