Update to v2.0.0-rc6 (#628)

* Update Rustdocs Links in Knowledgebase

* Upgrade Start a Chain

* Update Build a dApp

* Update Start a Private Network

* Update Create a Pallet

* Update Tutorial Versions

* Fix telemetry endpoints

Author: Dan Forbes

docs/knowledgebase/advanced/block-import.md

@@ -15,22 +15,22 @@ are later checked for validity and discarded if they are not valid. Elements tha
 imported into the node's local state.
 
 The import queue is codified abstractly in Substrate by means of the
-[`ImportQueue` trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/import_queue/trait.ImportQueue.html).
+[`ImportQueue` trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/import_queue/trait.ImportQueue.html).
 The use of a trait allows each consensus engine to provide its own specialized implementation of the
 import queue, which may take advantage of optimization opportunities such as verifying multiple
 blocks in parallel as they come in across the network.
 
 The import queue also provides some hooks via the
-[`Link` trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/import_queue/trait.Link.html) that can be used
+[`Link` trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/import_queue/trait.Link.html) that can be used
 to follow its progress.
 
 ## The Basic Queue
 
 Substrate provides a default in-memory implementation of the `ImportQueue` known as the
-[`BasicQueue`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/import_queue/struct.BasicQueue.html). The
+[`BasicQueue`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/import_queue/struct.BasicQueue.html). The
 `BasicQueue` does not do any kind of optimization, rather it performs the verification and import
 steps sequentially. It does, however, abstract the notion of verification through the use of the
-[`Verifier`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/import_queue/trait.Verifier.html) trait.
+[`Verifier`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/import_queue/trait.Verifier.html) trait.
 
 Any consensus engine that relies on the `BasicQueue` must implement the `Verifier` trait. The
 `Verifier` is typically responsible for tasks such as checking
@@ -41,12 +41,12 @@ the block is signed by the appropriate authority.
 
 When the import queue is ready to import a block, it passes the block in question to a method
 provided by the
-[`BlockImport` trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/block_import/trait.BlockImport.html).
+[`BlockImport` trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/block_import/trait.BlockImport.html).
 This `BlockImport` trait provides the behavior of importing a block into the node's local state
 database.
 
 One implementor of the `BlockImport` trait that is used in every Substrate node is the
-[`Client`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_service/client/index.html), which contains the node's entire
+[`Client`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_service/client/index.html), which contains the node's entire
 block database. When a block is imported into the client, it is added to the main database of blocks
 that the node knows about.
 
@@ -59,13 +59,13 @@ another struct that also implements `BlockImport`. This nesting leads to the ter
 pipeline".
 
 An example of this wrapping is the
-[`PowBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_pow/struct.PowBlockImport.html), which
+[`PowBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_pow/struct.PowBlockImport.html), which
 holds a reference to another type that also implements `BlockImport`. This allows the PoW consensus
 engine to do its own import-related bookkeeping and then pass the block to the nested `BlockImport`,
 probably the client. This pattern is also demonstrated in
-[`AuraBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_aura/struct.AuraBlockImport.html),
-[`BabeBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_babe/struct.BabeBlockImport.html), and
-[`GrandpaBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_finality_grandpa/struct.GrandpaBlockImport.html).
+[`AuraBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_aura/struct.AuraBlockImport.html),
+[`BabeBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_babe/struct.BabeBlockImport.html), and
+[`GrandpaBlockImport`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_finality_grandpa/struct.GrandpaBlockImport.html).
 
 `BlockImport` nesting need not be limited to one level. In fact, it is common for nodes that use
 both an authoring engine and a finality gadget to layer the nesting even more deeply. For example,

docs/knowledgebase/advanced/codec.md

@@ -201,7 +201,7 @@ that is written in Rust and maintained by Parity Technologies.
 ## References
 
 - Visit the reference docs for the
-  [`parity-scale-codec`](https://substrate.dev/rustdocs/v2.0.0-rc5/parity_scale_codec/index.html).
+  [`parity-scale-codec`](https://substrate.dev/rustdocs/v2.0.0-rc6/parity_scale_codec/index.html).
 
 - Visit the auxiliary encoding section of the
   [Polkadot runtime environment specification](https://github.com/w3f/polkadot-spec/).

docs/knowledgebase/advanced/consensus.md

@@ -50,7 +50,7 @@ parent. Forks must be resolved such that only one, canonical chain exists.
 
 A fork choice rule is an algorithm that takes a blockchain and selects the "best" chain, and thus
 the one that should be extended. Substrate exposes this concept through the
-[`SelectChain` Trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_consensus/trait.SelectChain.html).
+[`SelectChain` Trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_consensus/trait.SelectChain.html).
 
 Substrate allows you to write a custom fork choice rule, or use one that comes out of the box. For
 example:
@@ -59,7 +59,7 @@ example:
 
 The longest chain rule simply says that the best chain is the longest chain. Substrate provides this
 chain selection rule with the
-[`LongestChain` struct](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus/struct.LongestChain.html).
+[`LongestChain` struct](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus/struct.LongestChain.html).
 GRANDPA uses the longest chain rule for voting.
 
 ![longest chain rule](assets/consensus-longest-chain.png)
@@ -129,12 +129,12 @@ Developers are always welcome to provide their own custom consensus algorithms.
 
 ### Aura
 
-[Aura](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_aura/index.html) provides a slot-based
+[Aura](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_aura/index.html) provides a slot-based
 block authoring mechanism. In Aura a known set of authorities take turns producing blocks.
 
 ### BABE
 
-[BABE](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_babe/index.html) also provides slot-based
+[BABE](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_babe/index.html) also provides slot-based
 block authoring with a known set of validators. In these ways it is similar to Aura. Unlike Aura,
 slot assignment is based on the evaluation of a Verifiable Random Function (VRF). Each validator is
 assigned a weight for an _epoch._ This epoch is broken up into slots and the validator evaluates its
@@ -149,15 +149,15 @@ in a given slot. These "secondary" slot assignments allow BABE to achieve a cons
 
 ### Proof of Work
 
-[Proof-of-work](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_consensus_pow/index.html) block authoring
+[Proof-of-work](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_consensus_pow/index.html) block authoring
 is not slot-based and does not require a known authority set. In proof of work, anyone can produce a
 block at any time, so long as they can solve a computationally challenging problem (typically a hash
 preimage search). The difficulty of this problem can be tuned to provide a statistical target block
 time.
 
 ### GRANDPA
 
-[GRANDPA](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_finality_grandpa/index.html) provides block
+[GRANDPA](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_finality_grandpa/index.html) provides block
 finalization. It has a known weighted authority set like BABE. However, GRANDPA does not author
 blocks; it just listens to gossip about blocks that have been produced by some authoring engine like
 the three discussed above. GRANDPA validators vote on _chains,_ not _blocks,_ i.e. they vote on a
@@ -173,7 +173,7 @@ coordination with the runtime. Examples include adjustable difficulty in proof o
 rotation in proof of authority, and stake-based weighting in proof-of-stake networks.
 
 To accommodate these consensus features, Substrate has the concept of a
-[`DigestItem`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_runtime/enum.DigestItem.html), a message
+[`DigestItem`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_runtime/enum.DigestItem.html), a message
 passed from the outer part of the node, where consensus lives, to the runtime, or vice versa.
 
 ## Learn More

docs/knowledgebase/advanced/cryptography.md

@@ -9,7 +9,7 @@ This document offers a conceptual overview of the cryptography used in Substrate
 Hash functions are used in Substrate to map arbitrary sized data to fixed-sized values.
 
 Substrate provides two hash algorithms out of the box, but can support any hash algorithm which
-implements the [`Hasher` trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_core/trait.Hasher.html).
+implements the [`Hasher` trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_core/trait.Hasher.html).
 
 ### xxHash
 
@@ -39,7 +39,7 @@ Public-key cryptography is used in Substrate to provide a robust authentication
 
 Substrate provides multiple different cryptographic schemes and is generic such that it can support
 anything which implements the
-[`Pair` trait](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_core/crypto/trait.Pair.html).
+[`Pair` trait](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_core/crypto/trait.Pair.html).
 
 ### ECDSA
 
@@ -87,7 +87,7 @@ but only ECDSA signatures communicate their public key.
 ### References
 
 - Take a look at the
-  [`Hash`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_runtime/traits/trait.Hash.html) trait needed for
+  [`Hash`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_runtime/traits/trait.Hash.html) trait needed for
   implementing new hashing algorithms.
-- Take a look at the [`Pair`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_core/crypto/trait.Pair.html)
+- Take a look at the [`Pair`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_core/crypto/trait.Pair.html)
   trait needed for implementing new cryptographic schemes.

docs/knowledgebase/advanced/executor.md

@@ -69,7 +69,7 @@ needs to know the `spec_name`, `spec_version` and `authoring_version` of both th
 runtime.
 
 The runtime provides the following
-[versioning properties](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_version/struct.RuntimeVersion.html):
+[versioning properties](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_version/struct.RuntimeVersion.html):
 
 - `spec_name`: The identifier for the different Substrate runtimes.
 
@@ -128,10 +128,10 @@ TODO
 ### References
 
 - Check out the different
-  [Execution Strategies](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_client_api/execution_extensions/struct.ExecutionStrategies.html).
+  [Execution Strategies](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_client_api/execution_extensions/struct.ExecutionStrategies.html).
 
 - Take a look at the different
-  [Execution Strategy Options](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_state_machine/enum.ExecutionStrategy.html)
+  [Execution Strategy Options](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_state_machine/enum.ExecutionStrategy.html)
 
 - Review the
-  [Runtime Version definition](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_version/struct.RuntimeVersion.html).
+  [Runtime Version definition](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_version/struct.RuntimeVersion.html).

docs/knowledgebase/advanced/storage.md

@@ -46,7 +46,7 @@ each block header. This is used to easily verify the state of the blockchain and
 light clients to verify proofs.
 
 This trie only stores content for the canonical chain, not forks. There is a separate
-[`state_db` layer](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_state_db/index.html) that maintains the
+[`state_db` layer](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_state_db/index.html) that maintains the
 trie state with references counted in memory for all that is non-canonical.
 
 ### Child Trie
@@ -77,9 +77,9 @@ reading to learn how to calculate storage keys for the different types of storag
 To calculate the key for a simple [Storage Value](../runtime/storage#Storage-Value), take the
 [TwoX 128 hash](https://github.com/Cyan4973/xxHash) of the name of the module that contains the
 Storage Value and append to it the TwoX 128 hash of the name of the Storage Value itself. For
-example, the [Sudo](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_sudo/index.html) pallet exposes a
+example, the [Sudo](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_sudo/index.html) pallet exposes a
 Storage Value item named
-[`Key`](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_sudo/struct.Module.html#method.key):
+[`Key`](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_sudo/struct.Module.html#method.key):
 
 ```
 twox_128("Sudo")                   = "0x5c0d1176a568c1f92944340dbfed9e9c"
@@ -186,7 +186,7 @@ example, after you remove the first 32 hexadecimal characters that represent the
 
 ## Runtime Storage API
 
-Substrate's [FRAME Support crate](https://substrate.dev/rustdocs/v2.0.0-rc5/frame_support/index.html)
+Substrate's [FRAME Support crate](https://substrate.dev/rustdocs/v2.0.0-rc6/frame_support/index.html)
 provides utilities for generating unique, deterministic keys for your runtime's storage items. These
 storage items are placed in the [state trie](#Trie-Abstraction) and are accessible by
 [querying the trie by key](#Querying-Storage).
@@ -200,4 +200,4 @@ storage items are placed in the [state trie](#Trie-Abstraction) and are accessib
 ### References
 
 - Visit the reference docs for
-  [`paritytech/trie`](https://substrate.dev/rustdocs/v2.0.0-rc5/trie_db/trait.Trie.html).
+  [`paritytech/trie`](https://substrate.dev/rustdocs/v2.0.0-rc6/trie_db/trait.Trie.html).

docs/knowledgebase/integrate/chain-spec.md

@@ -8,7 +8,7 @@ and what consensus-critical state it must have at genesis.
 
 ## Structure of a Chain Spec
 
-The [`ChainSpec` struct](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_service/struct.GenericChainSpec.html)
+The [`ChainSpec` struct](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_service/struct.GenericChainSpec.html)
 separates the information contained in a chain spec into two parts. A node can use a `ChainSpec`
 instance to create a genesis block.
 
@@ -147,9 +147,9 @@ After the conversion process, the above snippet looks like this:
 ### Learn More
 
 - Rustdocs for the
-  [`ChainSpec` struct](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_service/struct.GenericChainSpec.html)
+  [`ChainSpec` struct](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_service/struct.GenericChainSpec.html)
 - Rustdocs for the
-  [`ProtocolId` struct](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_network/config/struct.ProtocolId.html)
+  [`ProtocolId` struct](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_network/config/struct.ProtocolId.html)
 
 ### Examples
 

docs/knowledgebase/learn-substrate/account-abstractions.md

@@ -25,13 +25,13 @@ These abstractions are:
   certain validator operations. They should never hold funds.
 
 > **Note:** Learn more about validators and nominators in the context of the Substrate's NPoS
-> [Staking module](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_staking/index.html).
+> [Staking module](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_staking/index.html).
 
 ## Account Keys
 
 A key pair can represent an account and control funds, like normal accounts that you would expect
 from other blockchains. In the context of Substrate's
-[Balances module](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_balances/index.html), these accounts
+[Balances module](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_balances/index.html), these accounts
 must have a minimum amount (an "existential deposit") to exist in storage.
 
 Account keys are defined generically and made concrete in the runtime.
@@ -78,7 +78,7 @@ Controller key. Then, they inform the chain that this key represents their Contr
 publishing the Session certificate in a transaction on the chain.
 
 Substrate provides the
-[Session module](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_session/index.html), which allows
+[Session module](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_session/index.html), which allows
 validators to manage their session keys.
 
 ### Strongly Typed Wrappers
@@ -96,7 +96,7 @@ used for their intended purpose.
 
 If a Session key is compromised, attackers could commit slashable behavior. Session keys should be
 changed regularly (e.g. every session) via
-[the `rotate_keys` RPC](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_rpc/author/trait.AuthorApi.html#tymethod.rotate_keys)
+[the `rotate_keys` RPC](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_rpc/author/trait.AuthorApi.html#tymethod.rotate_keys)
 for increased security.
 
 ## Next Steps
@@ -113,11 +113,11 @@ for increased security.
 ### References
 
 - Visit the reference docs for the
-  [session keys runtime API](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_session/trait.SessionKeys.html).
+  [session keys runtime API](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_session/trait.SessionKeys.html).
 
 - Take a look at the default
-  [session keys in the Substrate node runtime](https://substrate.dev/rustdocs/v2.0.0-rc5/node_runtime/struct.SessionKeys.html).
+  [session keys in the Substrate node runtime](https://substrate.dev/rustdocs/v2.0.0-rc6/node_runtime/struct.SessionKeys.html).
 
 - Take a look at
-  [`substrate_application_crypto`](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_application_crypto/index.html),
+  [`substrate_application_crypto`](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_application_crypto/index.html),
   used for constructing application specific strongly typed crypto wrappers.

docs/knowledgebase/learn-substrate/extrinsics.md

@@ -21,7 +21,7 @@ First, it prevents any alterations to the series of extrinsics after the header
 distributed. Second, it provides a means of allowing light clients to succinctly verify that any
 given extrinsic did indeed exist in a block given only knowledge of the header.
 
-- [Block Reference](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_runtime/traits/trait.Block.html)
+- [Block Reference](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_runtime/traits/trait.Block.html)
 
 ## Inherents
 
@@ -39,7 +39,7 @@ to prove that a timestamp is true the way the desire to send funds is proved wit
 Rather, validators accept or reject the block based on how reasonable the other validators find the
 timestamp, which may mean it is within some acceptable range of their own system clocks.
 
-- [Inherents Reference](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_inherents/index.html)
+- [Inherents Reference](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_inherents/index.html)
 
 ## Signed Transactions
 
@@ -83,11 +83,11 @@ Despite the name, `SignedExtension` can also be used to verify unsigned transact
 `*_unsigned` set of methods can be implemented to encapsulate validation, spam, and replay
 protection logic that is needed by the transaction pool.
 
-- [Signed Extension Reference](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_runtime/traits/trait.SignedExtension.html)
+- [Signed Extension Reference](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_runtime/traits/trait.SignedExtension.html)
 
 ## Further Reading
 
-- [Reference Documentation](https://substrate.dev/rustdocs/v2.0.0-rc5/sp_runtime/traits/trait.Extrinsic.html)
+- [Reference Documentation](https://substrate.dev/rustdocs/v2.0.0-rc6/sp_runtime/traits/trait.Extrinsic.html)
 - [Runtime Execution](../runtime/execution)
 - [Transaction Fees](../runtime/fees)
 - [Transaction Pool](../learn-substrate/tx-pool)

docs/knowledgebase/learn-substrate/session-keys.md

@@ -42,7 +42,7 @@ mod app {
 > Refer to the runtime for the most up-to-date implementation.
 
 The default Substrate node implements Session keys in the
-[Session pallet](https://substrate.dev/rustdocs/v2.0.0-rc5/pallet_session/index.html).
+[Session pallet](https://substrate.dev/rustdocs/v2.0.0-rc6/pallet_session/index.html).
 
 ## Generation and Use
 
@@ -53,5 +53,5 @@ behavior.
 
 Session keys may be changed regularly (e.g. every session) for increased security. Node operators
 can generate them via the RPC call
-[`author_rotateKeys`](https://substrate.dev/rustdocs/v2.0.0-rc5/sc_rpc/author/trait.AuthorApi.html#tymethod.rotate_keys).
+[`author_rotateKeys`](https://substrate.dev/rustdocs/v2.0.0-rc6/sc_rpc/author/trait.AuthorApi.html#tymethod.rotate_keys).
 You will then need to register the new keys on chain with a `session.setKeys` transaction.