Is your feature request related to a problem? Please describe.

I've decoupled my consumption from my checkpointing (i.e., I don't necessarily synchronously process all change feed items, instead letting reading get ahead of the checkpointable position in order that I can manage buffering and retries for performance)

Describe the solution you'd like

Provide an overload that exposes something akin to the IChangeFeedProcessorContext.CheckpointAsync method which the v2 CFP API formerly exposed (it's present but internal atm)

Describe alternatives you've considered

Only alternative is to use the v2 CFP SDK, but that closes off tonnes of options and is not tenable from my perspective.

Additional context

• I flagged this to @ealsur some time ago in the context of some other work in this repo. While Port to Azure.Cosmos / v3 SDK jet/equinox#144 illustrates that the V3 SDK provides some very nice cleanup in general for a relatively complex use case, not being able to port the CFP aspect easily presents a problem in the medium term with having client teams adopt the V3 SDK.

• Consumption code

  • shows how we use (and need, CheckpointAsync)
  • illustrates that in general, the V3 API is good - it will cut out a lot of boilerplate wrapping we formerly had to provide.
  • never lets an exception escape from the processor observer function, avoiding the fact that the CFP logic does not retry and/or otherwise correctly handle exceptions.
  • illustrates the level of instrumentation (i.e. context re logging Range Ids etc) which cannot be exposed at the present time due to the absence of IChangeFeedProcessorContext (see related: Provide partitionid to ChangeFeedObserverFactory.Create #400)

• Document parsing code

  • this code cannot be directly ported due to the fact that the Document class has become internal in V3 - it'd be nice to have a sample illustrate how one might most cheaply probe documents to determine whether they are parseable as a given type as was formerly possible.