Fix SQL Import for Soft Delete and History

[mikaelweave]

Description

Adds support for importing versioned and deleted resources. This is especially useful for migrating between FHIR instances.

This PR adds the below behavior:

• Importing with versionId and lastUpdated will result in all versions from an import input file being imported.
  • Previously some versions were skipped (see below).

This is on top of existing behavior which, while not addressed in this PR, is useful for context.

• Importing without both versionId and lastUpdated means some versions of the resource may not be imported.
  • The code tries to use the latest resource if lastUpdated exists.
• Importing deleted resources may be skipped (unless versionId and lastUpdated are specified).

I've added E2E tests to ensure resources are properly imported mostly around new behavior but also the existing behavior.

Related issues

AB #105536

Testing

• New E2E tests which cover various scenarios of deleted/updated resources (new and existing).
• Manual testing

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

[mikaelweave]

@SergeyGaluzo - since I had the environment up for export test, I ran $import with this new code one two separate new DBs - one with release branch image and one with the code from this branch. I ran $import using the same sample DB you provided - difference between both runs is about 0.3% (almost nothing). Passed the test - merging this code.