anchor.diff:  
   === Connector Restarts
   
  -So now we have demonstrated that the incremental snapshot can be (re-)started as needed.
  +So now we have demonstrated that using the notion of incremental snapshots, the same table(s) can be snapshotted repeatedly, if and when needed.
   We have shown that its execution does not stop streaming from the transaction log.
   The last item is termination and/or resuming of the process.
   
  
positive.code: be it intentionally or after a crash.
  Upon connector start, the component responsible for the snapshotting reads the data from the offsets.
  It initializes its internal state and resumes snapshotting after the last processed event.
  
  This approach ensures the robustness of the process, resilience to restarts and crashes, and minimizes the number of redelivered events (at-least-once delivery semantics still apply).
  
  
negative.code: The incremental snapshotting has few drawbacks in comparison to the initial consistent snapshot:
  
  * The snapshotted table must contain primary keys
  * If an event is deleted from the table during the snapshotting process, then one of these situations can happen:
  ** A `read` event and a `delete` event are received by downstream consumers
  ** Only a `delete` event is be received
  * If an event is updated in the table during the snapshotting process, then one of the situations can happen:
  ** A `read` event and an `update` event are received by downstream consumers
  ** An `update` event and `read` event are received (note the opposite order)
  ** Only an `update` event is received (in case the update happened within the chunk that would have emitted the `read` event)
  
  In general, `read` events should not be understood as the initial state of the record in a table, but as the state of the record at an arbitrary point of time.
  Semantics for consumers are slightly changed in comparison to traditional initial snapshots in Debezium,
  