instance-level history does not reflect the "actual" http method or response code in certain cases

[lmsurpre]

For system and type-level history interactions, we now convey the proper http method and response code for each interaction (driven by the change_log table - #3507)

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.

To Reproduce

• create a resource via PUT (create-on-update)
• delete it
• update it (bringing it "back to life")
• invoke instance-level history

Note that

• version 1 of the resource says it was a POST (even though it was a PUT).
• version 3 of the reosurces says it has a response status of 200 but it was actually a 201

Originally posted by @lmsurpre in https://github.com/IBM/FHIR/issues/3507#issuecomment-1081157116

[lmsurpre]

https://www.hl7.org/fhir/http.html#history

New resources or updates to existing resources that are triggered by operations also appear in the history, as do updates to the resources that result from interactions outside the scope of the RESTful interface.

However, the history bundle structure has no way of representing such changes because Bundle.entry.request.method is 1..1 and has a required binding to HTTPVerb values (GET, POST, PUT, ...).