Fix SQL export queuing

[LTA-Thinking]

Description

Fixes a bug where an export job couldn't be queued if it used a container that had be used before.

What was happening was the duplication detection was preventing jobs with the same container from being queued. Since the queued time was being hardcoded in the job definition the only source of difference between jobs with the same URL was the container. If the container wasn't specified it was set to a random GUID and jobs could be queued as normal. But if the container was specified only one job would be queued per unique URL. Any future requests with the same URL would match against the old job definition and not start a new job.
By adding a Till time that is set to the time the request was made it allows the jobs to be differentiated and multiple jobs can be made with the same container. The Queued time was implicitly acting as the Till time up to this point, but calling it out as an explicit parameter will make it more clear what it is used for and allow for it to be set as a query parameter in the future.

This only happened in SQL.

Related issues

Addresses [issue #].

Testing

Manual and existing E2E tests. This issue was found by the Export Job Tests.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 50 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, Dependencies, Enhancement, or New-Feature
• Tag the PR with Azure API for FHIR if this will release to the Azure API for FHIR managed service (CosmosDB or common code related to service)
• Tag the PR with Azure Healthcare APIs if this will release to the Azure Healthcare APIs managed service (Sql server or common code related to service)
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch

[LTA-Thinking]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).