Feedback: MOLT Fetch - document replication rationale and cutover strategy

Page: https://cockroachlabs.com/docs/molt/molt-fetch.html

## What is the reason for your feedback?

[X] Missing the information I need

[ ] Too complicated

[ ] Out of date

[ ] Something is broken

[ ] Other

## Additional details

The MOLT Fetch docs need to describe the rationale for using a replication approach, and describe the strategy for cutting over from the source database to CockroachDB.

Regarding the rationale for using the MOLT Fetch replication functionality, the doc should say something along the lines of:

> MOLT Fetch supports low-downtime migrations by providing a replication mode of operation. With replication mode, the downtime required is shorter because you do not need to wait for all the source data to be transferred to CockroachDB. Instead, you only have to wait for the replication pipeline to drain, which takes much less time.

Regarding the strategy for cutting over from the source database to CockroachDB, the doc should say something along the lines of:

> When using replication, the approach for the cutover to CockroachDB is: (1) stop performing writes on the old database, (2) wait for the replication pipeline to drain, then (3) start performing writes to CockroachDB.

It should also document how the customer can know when the replication pipeline has finished draining so they can move from step 2 to 3. It should say something along the lines of:

> You can infer that replication pipeline has drained from seeing no more replication activity. You can see this activity in two places:
>
> 1. Looking at the Replicator logs, once there is no more activity, you would no longer see upserted rows. The Replicator logs should show something like `info upserted rows: 0`
>
> 2. There is also a Replicator metric that shows throughput. Once you see that as 0 rows/sec then the replication pipeline should be drained.

Jira issue: DOC-13256