[skip ci]Format markdown doc for proxy.md (#10000)

Signed-off-by: ruiyi.jiang <ruiyi.jiang@zilliz.com>

docs/design_docs/proxy.md

@@ -27,7 +27,7 @@ search requests for example, Proxy should check if the related collection exists
 
 Also, Proxy will do some preprocessing for every request. Proxy will do little thing for some requests in the
 preprocessing stage and a lot more for other requests. Every object in Milvus will be assigned with a `ID`, such as
-`CollectionID`, `PartitionID`, `IndexID`,  `SegmentID` and etc. Components in Milvus communicate with each other by the 
+`CollectionID`, `PartitionID`, `IndexID`, `SegmentID` and etc. Components in Milvus communicate with each other by the
 ID of object, however, users only knows the object name. So as the user access layser of Milvus, Proxy should translate
 the object name into object ID. Also taking search request as example, Proxy should translate the `CollectionName` into
 `CollectionID` and then the Query Node will recognize the request. Proxy holds a cache that translate object name into
@@ -45,26 +45,24 @@ lease in etcd. Otherwise, if some exceptions occurred in a node, or a node stopp
 the related node information. By using this mechanism, nodes in Milvus know if there are any other nodes going to be
 online or offline and synchronize the latest node information.
 
-
-
 #### 6.0 Interaction with Root Coordinator
 
 Proxy will forward the DdRequest to Root Coordinator. These requests include:
 
-	- CreateCollection
-	- DropCollection
-	- HasCollection
-	- DescribeCollection
-	- ShowCollections
-	- CreatePartition
-	- DropPartition
-	- HasPartition
-	- ShowPartitions
-	- CreateIndex
-	- DropIndex
-	- DescribeIndex
-	- GetIndexBuildProgress
-	- GetIndexState
+    - CreateCollection
+    - DropCollection
+    - HasCollection
+    - DescribeCollection
+    - ShowCollections
+    - CreatePartition
+    - DropPartition
+    - HasPartition
+    - ShowPartitions
+    - CreateIndex
+    - DropIndex
+    - DescribeIndex
+    - GetIndexBuildProgress
+    - GetIndexState
 
 Proxy handles the DdRequest sequentially. When and only when the earlier entered requests are done, the next request
 would be handled. Proxy forwards these requests to Root Coordinator, waits until getting results from Root Coordinator, and then
@@ -227,9 +225,9 @@ Collection and Partition.
 
 There are three main functions in taskScheduler:
 
-	- Schedule task
-	- Maintain the snapshot of timestamp statistics
-	- Receive the search results from stream and then distribute them to related task
+    - Schedule task
+    - Maintain the snapshot of timestamp statistics
+    - Receive the search results from stream and then distribute them to related task
 
 taskScheduler maintains three queues: ddQueue, dmQueue and dqQueue correspond to DdRequest, DmRequest, and DqRequest
 respectively. The interface of taskQueue is defined as follows:
@@ -366,7 +364,7 @@ writes the request to the DqRequestChannel, it will attach the ReqID, and the qu
 when writing the search result back to the DqResultChannel. taskScheduler will start a background coroutine to consume
 search result from DqResultChannel, and then distribute messages according to the ReqID in it. When several results of
 the same ReqID are collected and the termination condition is reached, these results will be passed to the blocking task
-coroutine which is  waiting. The waken task will reduce the search results and then send the final search result to
+coroutine which is waiting. The waken task will reduce the search results and then send the final search result to
 clients.
 
 ##### 6.6.2 channelsMgr