Spark V2->V3 Migration doc is missing the throughput control section (Azure#36269)

Author: rinatmini

sdk/cosmos/azure-cosmos-spark_3_2-12/docs/migration.md

@@ -17,7 +17,7 @@
 | changefeedmaxpagesperbatch | spark.cosmos.changeFeed.itemCountPerTriggerHint | |
 | WritingBatchSize | spark.cosmos.write.bulk.maxPendingOperations | Recommendation would be to start with the default (not specifying this config entry - and only adjust (reduce) it when really necessary|
 | Upsert | spark.cosmos.write.strategy | If you use `ItemOverwrite` here the behavior is the same as with Upsert==true before |
-| WriteThroughputBudget | spark.cosmos.throughputControl.* | See the `Throughput control` section below|
+| WriteThroughputBudget | spark.cosmos.throughputControl.* | See the [Throughput control](https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos-spark_3_2-12/docs/scenarios/Ingestion.md#throughput-control) section for more information |
 | MaxIngestionTaskParallelism | n/a | Not relevant anymore - just remove this config entry |
 | query_pagesize | n/a | Not relevant anymore - just remove this config entry |
 | query_custom | spark.cosmos.read.customQuery | When provided the custom query will be processed against the Cosmos endpoint instead of dynamically generating the query via predicate push down. Usually it is recommended to rely on Spark's predicate push down because that will allow to generate the most efficient set of filters based on the query plan. But there are a couple of of predicates like aggregates (count, group by, avg, sum etc.) that cannot be pushed down yet (at least in Spark 3.1) - so the custom query is a fallback to allow them to be pushed into the query sent to Cosmos. |