"Undelete" action is logged as an update in the changes table but a create in audit

[lmsurpre]

Describe the bug
We're somewhat inconsistent in the way we handle the "undelete" case (an update after a delete).

Our server returns a 201 (Created) status and we now log this as a create in the audit log (as of #2471).

This matches what the spec says (from https://www.hl7.org/fhir/http.html#delete)

If the interaction is successful, the server SHALL return either a 200 OK HTTP status code if the resource was updated, or a 201 Created status code if the resource was created (or brought back to life/re-created)

Prior to #3293 we were calling the beforeUpdate and afterUpdate methods for this case.
Therefor, the notification events we emitted also called this an update.
But now that the "prevResource" is null for this "undelete" case, we now call beforeCreate and afterCreate and therefor this interaction will lead to a create action code in the notification event going forward.
Furthermore, we also call FHIRPersistence.create (rather than FHIRPersistence.update).

However, when we insert into the RESOURCE_CHANGE_LOG table, we're still setting the changeType to U (and not C).
This leads to the _history api using the status code 200 for these requests, even though the actual status code was a 201.

Environment
main

To Reproduce
Steps to reproduce the behavior:

1. create a resource
2. delete it
3. update it (bringing it "back to life")
4. invoke system or type-level history

Note that the entry for step 3 indicates that the result was 200 OK even though the actual interaction resulted in a 201 Created

Expected behavior
The history api returns a status code that accurately reflects the actual status code for the "undelete" interaction.

Additional context
Originally identified at #2988 (comment)

[lmsurpre]

I think it will require an update to the stored procedures (and to DerbyResourceDAO)

[lmsurpre]

For system and type-level history interactions, we can easily start writing those to the CHANGE_LOG table as creates ('C') rather than updates ('U').

However, for instance-level history its not so simple due to the following limitations of the current approach:

1. if versionId is 1, we don't know if it was created via a POST or a PUT (we always say POST)
2. else, we can tell if its a PUT vs a DELETE, but in the case of a PUT we cannot reliably determine if its an "update after delete" unless we update the REST layer to retrieve a ResourceResult for the last entry from the prior page

To address both points (so that the Bundle.entry.response element always reflects the proper HTTP method and response status of that specific interaction) I think we'd need to reimplement this instance-level history on top of the CHANGE_LOG table.

For now, I'm thinking to just fix the system and type-level interactions... maybe we can open a separate issue for the instance-level history?

[d0roppe]

From testing this with the latest code, I am still seeing code 200 on a recreate for the _history

[lmsurpre]

From testing this with the latest code, I am still seeing code 200 on a recreate for the _history

That is mentioned as a limitation of the current approach for instance-level history just above.
I've now opened #3554 to track that.

[d0roppe]

With verifying this for whole system history and type history this is working as expected.