[FAB-9176] Fix some docs issue

Change-Id: Ibfd30c6b51c32fac927b35a711d8663177099f55
Signed-off-by: Zhenguo Niu <Niu.ZGlinux@gmail.com>

Author: niuzhenguo

docs/source/msp.rst

@@ -301,7 +301,7 @@ as orderers).
 
 There is limited support for such requirements.
 
-One way to allow for this separation is to to create a separate intermediate
+One way to allow for this separation is to create a separate intermediate
 CA for each node type - one for clients and one for peers/orderers; and
 configure two different MSPs - one for clients and one for peers/orderers.
 Channels this organization should be accessing would need to include

docs/source/peers/peers.md

@@ -155,7 +155,7 @@ peers, where they can be verified before being applied to each peer's local copy
 of the ledger. As this whole ordering processing takes some time to complete
 (seconds), the application is notified asynchronously, as shown in step five.
 
-Later in this topic, you'll learn more about the detailed nature of of this
+Later in this topic, you'll learn more about the detailed nature of this
 ordering process -- and for a really detailed look at this process see the
 [Transaction Flow](../txflow.html) topic.
 
@@ -435,7 +435,7 @@ happen -- the blocks generated by a collection of orderers are said to be
 **final** because once a transaction has been written to a block, its position
 in the ledger is immutably assured. Hyperledger Fabric's finality means that a
 disastrous occurrence known as a **ledger fork** cannot occur. Once transactions
-are captured in a block, history cannot be be rewritten for that transaction at
+are captured in a block, history cannot be rewritten for that transaction at
 a future point in time.
 
 We can see also see that whereas peers host the ledger and chaincodes,
@@ -512,7 +512,7 @@ the chaincodes (the transaction proposal responses) which are shared to every
 peer in the channel, whether or not they endorsed the transaction. This
 specialization of endorsing peers is designed to help scalability.
 
-Finally, every time a block is committed to to a peer's ledger, that peer
+Finally, every time a block is committed to a peer's ledger, that peer
 generates an appropriate *event*. *Block events* include the full block content,
 while *block transaction events* include summary information only, such as
 whether each transaction in the block has been validated or invalidated.

docs/source/policies.rst

@@ -407,7 +407,7 @@ Note that policies higher in the hierarchy are all defined as
 ``SignaturePolicy``\ s. This set of defaults works nicely because the
 ``ImplicitMetaPolicies`` do not need to be redefined as the number of
 organizations change, and the individual organizations may pick their
-own rules and thresholds for what is means to be a a Reader, Writer, and
+own rules and thresholds for what is means to be a Reader, Writer, and
 Admin.
 
 .. Licensed under Creative Commons Attribution 4.0 International License

docs/source/upgrading_your_network_tutorial.rst

@@ -229,7 +229,7 @@ we will perform the following steps:
 1. Stop the peer.
 2. Back up the peer’s ledger and MSP.
 3. Remove chaincode containers and images.
-4. Restart the peer with with latest image.
+4. Restart the peer with latest image.
 5. Verify upgrade completion.
 
 We have four peers running in our network. We will perform this process once for