Avoid storing the resource contents in the case of a soft delete

[lmsurpre]

Is your feature request related to a problem? Please describe.
In versioned FHIR servers (like ours), the DELETE action is a "soft delete"... its actually more like an update where we set the delete flag to Y.

Despite the resource content being logically deleted, for historical reasons we always write a new version of the entire resource payload in the db on this deleted version.

Describe the solution you'd like
Stop writing the resource payload on the deleted version of this record.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context
In a previous iteration of the DB, I think we always needed non-null data for the x_Resources tables.
We may have a few places that still assume you can read it back out (maybe audit?), but we think we can manage those.

[lmsurpre]

this one has wide blast radius...

1. verify that the x_resources rows for deletes have no resource payload content
2. "full regression" to make sure things are working as expected, especially after some soft deletes
   • e2e tests (fhir-server-test)
   • touchstone tests

then:
* search performance bucket
* dag/karen have some other local tests including the below

Rough manual test plan:

• create a resource
• delete the resource
• undelete the resource (PUT with same id)
• delete the resource

Then make sure all the following work:

• conditional delete
• if-none-match
• if-none-match within a bundle
• $erase
• $export

[lmsurpre]

I confirmed that the rows in the x_resources table that correspond to deleted versions now have a null data column:

and I manually tested re-delete, revive-delete, and conditional delete cases.

[lmsurpre]

I deployed this one to our cluster on IBM Cloud and ran the touchstone conformance tests against it. 100% successful.

[kmbarton423]

confirmed conditional delete is working as expected
did write up an enhancement issue #3419

[kmbarton423]

confirmed if-none-match and if-none-match within a bundle functionality

[kmbarton423]

confirmed $erase functionality
found issue #3439 during testing but it appears to be unrelated to these changes for soft delete

[lmsurpre]

issue #3439 has been addressed and this feature seems to be working