Adding Change Feed Processor code migration sample

[ealsur]

Pull Request Template

Description

Adding a sample to cover code migration from the Change Feed Processor library (SDK V2) to V3 SDK.

[ealsur]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[bartelink]

Can the 'new CFP' emit a message when a range is assigned / unassigned? (Yes, I'm attempting to once again draw attention to #400 :P)

(As a workaround, does the v3 lib still use Liblog so I can at least echo such status changes to the console) ?

[ealsur]

We are actually discussing that this week. I can add Traces you can hook to as a Diagnostics Source here: https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/ChangeFeedProcessor/FeedProcessing/ChangeFeedObserverBase.cs#L23

[bartelink]

I believe that would be a very important feature (also the assignment side is equally interesting to be able to log timings of etc)

A useful thing in the context of this PR might also be to log when batches are obtained in the new API (or am I missing it?)

---

This does bring me to a second set of requirements in this space, which are covered in #616:

• being able to let the processor read multiple batches ahead [and then do manual checkpointing under control of a processor]. (But being able to provide backpressure as was possible with the V2 API by sleeping until such time as sufficient progress has been made in order to prevent avoid excess memory consumption)
• be able to distinguish from which rangeId a given batch was obtained (in order to be able to ensure that each assigned range's reading only gets a certain amount ahead)
• (for avoidance of doubt, AIUI, the logic is still identical?) being able to handle messages from all assigned ranges concurrently (i.e. if one observer sleeps, the others should continue to loop)
• (being able to signal that a range assignment has been revoked, which would be achieved by the CloseAsync hook)

(I know this is quite the tangent for a PR discussion; I believe the two cited issues sum up the concerns and needs, but am happy to expand on them and/or consolidate them if desired)

[bartelink]

I added a comment to #400 (comment) summarizing the bulk of these tangential concerns, which might represent a better place to discuss such things.

As noted earlier, the basic logging hooks probably make sense to consider in the context of this particular PR (though manual checkpointing support #616 might inform the API design)