Fix search with include and sort

[LTA-Thinking]

Description

When using _sort and _include/_revinclude together there are issues when there are enough included resources to create an include continuation token.

• If sorting by last updated descending the included results won't be in the bundle and no include continuation token will be returned.
• If sorting by any other field it will cause a 500 if there are enough results with the sort field to fill a page of data.
• If during a search the number of matched results with the sort value isn't enough to fill a page, but is enough to generate an includes continuation token, the includes continuation token will be lost when the second search is run to get results that don't contain the sort value.
• If an includes continuation token is used with a sort field it will get data for both matches that contain the sort field and those that don't contain the sort field regardless of which type of matched result generated the includes continuation token.

This PR fixes all of these issues.

Related issues

Addresses Bug 177120

Testing

Manual testing and new E2E tests.

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.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch

[mikaelweave]

A couple questions

[mikaelweave]

I know a lot this code was existing but I'm seeing a lot of magic numbers in this block. Any chance you can add some comments to improve readability for those new to this area?

[mikaelweave]

Is a BadRequestException correct here? If the token is malformed is it an issue from the client or in our code?

[LTA-Thinking]

I think the safer expectation is that the client passed in the wrong value for the CT. It is possible for us to have a bug in the CT generation code, but I don't think that is the right assumption to take with a user provided value.

[LTA-Thinking]

There are still more edge cases to fix here. The behavior when using a second phase includes continuation token after the second page of first phase includes results isn't working correctly.