As part of the batch-mode implementation, the connector needs to know if the
server supports change streams at all. If it doesn't, this will be a fast path
toward making the capture bindings all default to batch-mode, among other
things.

…Length

The latest MongoDB driver provides a RemainingBatchLength method for change
streams, and this changes the change stream processing code to make use of that
for simplifications and some slight optimizations.

`tryStream` has been refactored in `pullStream`, which will request one batch of
documents from the change stream cursor, emit them all, and then return.
Higher-level termination conditions can be handled by the caller.

An optimization implemented here is to not checkpoint unless a document is
actually being emitted, or to catch the post-batch resume token. This was
previously not possible because `TryNext` could return true forever if there was
a high rate of changes on the server, and if they were exclusively for
non-tracked collections we would never have emitted a checkpoint in that case.

An additional optimization is to quickly check if the received event is for a
tracked collection and discard it if it isn't. This may help with cases where a
very busy database is being watched, but only a few of its collections are
captured.

…ordinator

Further refactoring and streamlining of the change stream code path: There will
be just one `streamChanges` function, and it can be configured to return or not
once streams are caught up. Returning in this way will be done for intermittent
streaming while backfilling incremental change stream collections, and the
change streams will run forever after those collections are done backfilling.

This is partially enabled by the new batch/stream coordinator apparatus, which
will be utilized in later commits to support concurrent change streams & batch
backfills of non-incremental change stream collections.

Adds configuration options for capturing MongoDB collections in "batch" mode,
and support for initial discovering those kinds of collections. Proper support
for discovering time series collections (which will have a different id field)
will come later, along with the implementation for incremental batch bindings
that use a cursor.

…ollections

Some initial restructuring of the backfill code path to make it more amenable
to also handling "batch" collections which will re-backfill over and over again
forever on a schedule.

…as incremental change stream bindings

Enables capturing documents from batch snapshot bindings concurrently with
on-going incremental change streaming

The connector will prioritize getting one-shot backfills done for collections
using change streams for on-going change data capture. Once those backfills are
done, both batch bindings and change streams will run indefinitely. During this
time the batchStreamCoordinator will signal the batch bindings to pause and
allow the change streams to fully catch up occasionally.

Adds the changes needed to actually support capturing incremental batch bindings
with or without a custom cursor value.

The only kind of collection that will be discovered as an incremental batch
binding is a time series collection, and the cursor will automatically be
determined as the timestamp field for the collection.

The main change here is to make updateResourceStates know that it can reset a
database change stream token if all of the change stream bindings (only) have
been reset. Batch bindings do not 'count' for needing to retain the database
change stream cursor.

As a bit of a convenience, prevent the user from changing the cursor field by
returning an error during the Validate call if the cursor field is attempted to
be changed.

If the cursor field must be changed, re-backfilling the binding will allow that
to happen. Without a backfill, changing the cursor field would have
unpredictable and almost certainly not desired effects.

Adds a rigorous test for change stream correctness that simulates capturing from
several streams on a database under some load.

Fixes a handful of bugs I found when doing some final Q/A tests, including:

* Don't panic when getting server info if there are 0 configured bindings
* Discovery must discover bindings in batch mode if the server doesn't support
  change streams
* Correctly get server info in Validate, and compare empty resource mode with
  change stream requirements using the implicit default

Also re-ordered the resource configuration fields for cursor & poll schedule to
make a little more intuitive sense hopefully.