fix: minor documentation update (#3572)

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
- [ ] Make sure to open an issue as a [bug/issue](https://github.com/googleapis/java-bigtable-hbase/issues/new/choose) before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
- [ ] Ensure the tests and linter pass
- [ ] Code coverage does not decrease (if any source code was changed)
- [ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> ☕️

If you write sample code, please follow the [samples format](
https://github.com/GoogleCloudPlatform/java-docs-samples/blob/main/SAMPLE_FORMAT.md).

Author: vermas2012

hbase-migration-tools/bigtable-hbase-replication/README.md

@@ -60,8 +60,8 @@ data. Near zero downtime migrations include the following steps:
 3. Update hbase-site.xml with destination cloud bigtable project id, instance id
    and service account json file.
 4. Add a CBT replication peer in HBase. On HBase shell
-   execute `add_peer '2', ENDPOINT_CLASSNAME => 'com.google.cloud.bigtable.hbase.replication.HbaseToCloudBigtableReplicationEndpoint'`
-   . Use add_peer options to enable replication for select tables.
+   execute `add_peer '2', ENDPOINT_CLASSNAME => 'com.google.cloud.bigtable.hbase2_x.replication.HbaseToCloudBigtableReplicationEndpoint'`
+   . Please use endpoint class `com.google.cloud.bigtable.hbase1_x.replication.HbaseToCloudBigtableReplicationEndpoint` for HBase 1.x clusters. Use add_peer options to enable replication for select tables.
 5. Immediately disable the CBT replication peer, this allows WAL logs to
    accumulate on HDFS. On HBase shell execute:  `disable_peer '2'`
 6. Check the replicated tables by executing `list_replicated_tables` and enable
@@ -111,6 +111,10 @@ classpath.
 </property>
 ```
 
+We recommend specifying a single-cluster routing [application profile](https://cloud.google.com/bigtable/docs/app-profiles#routing) by setting config key 
+`google.bigtable.app_profile.id`. A single-cluster routing application profile
+preserves order of mutations between HBase and Cloud Bigtable. 
+
 Next, you should configure Cloud Bigtable authentication. Create a service
 account and download a json file as shown
 [here](https://cloud.google.com/docs/authentication/production#create_service_account)
@@ -189,7 +193,7 @@ that can be modified during WAL write.
 
 |Type of mutation |HBase WAL Write behavior |CBT replication library action|
 |-----------------|-------------------------|------------------------------|
-|DeleteLatestVersion|Resolves the latest version and writes a deletecell with timestamp|Supported, as its normal deletecell
+|DeleteLatestVersion|Resolves the latest version and writes a deletecell with timestamp|Supported, as its normal deletecell|
 |DeleteFamilyAtVersion|Not modified|Logged and skipped|
 |DeleteFamilyBeforeTimestamp|Not modified|Converts it to DeleteFamily if timestamp within a configurable threshold.|
 |DeleteFamily|Converts to DeleteFamilyBeforeTimestamp with timestamp=now|See DeleteFamilyBeforeTimestamp|
@@ -232,7 +236,7 @@ in `hbase-site.xml` but we recommend setting it during peer creation.
 Enabling/disabling dry run mode during peer creation can avoid restarting the
 HBase cluster to pickup changes to `hbase-site.xml` file. Enable dry run mode by
 running the following command to add Cloud Bigtable replication peer (please
-change the endpoint class for HBase 1.x):
+change the endpoint class to `com.google.cloud.bigtable.hbase1_x.replication.HbaseToCloudBigtableReplicationEndpoint` for HBase 1.x):
 
 ```
 add_peer 'peer_id',

hbase-migration-tools/bigtable-hbase-replication/bigtable-hbase-replication-core/src/main/java/com/google/cloud/bigtable/hbase/replication/configuration/HBaseToCloudBigtableReplicationConfiguration.java

@@ -54,6 +54,18 @@ private HBaseToCloudBigtableReplicationConfiguration() {}
   // TODO maybe it should depend on the number of processors on the VM.
   public static final int DEFAULT_THREAD_COUNT = 10;
 
+  /**
+   * Determines the size of request to CBT. This parameter controls the number of concurrent RPCs to
+   * Cloud Bigtable.
+   *
+   * <p>Set it to higher value to reduce concurrency, setting it to a value >
+   * replication.source.size.capacity will result in a single batch of writes to Cloud Bigtable per
+   * CBTEndpoint replicate call.
+   *
+   * <p>Set it to a smaller value to send small batches with max concurrency of
+   * "google.bigtable.replication.thread_count". This will result in lower replication lag for Cloud
+   * Bigtable at the expense of more RPCs.
+   */
   public static final String BATCH_SIZE_KEY = "google.bigtable.replication.batch_size_bytes";
   // TODO: Tune this parameter. Usually, this should be smaller than the HBase replication source
   // batch capacity by counts and bytes. These capacity are set by `replication.source.nb.capacity`