Prepare documentation for v0.36.x backport branch. (#8705)

- Remove RFCs and ADRs from v0.36.x backport branch.
- Update branch-relative links.

docs/tendermint-core/block-structure.md

@@ -11,6 +11,6 @@ nodes. This blockchain is accessible via various RPC endpoints, mainly
 `/blockchain?minHeight=_&maxHeight=_` to get a list of headers. But what
 exactly is stored in these blocks?
 
-The [specification](https://github.com/tendermint/tendermint/tree/master/spec/core/data_structures.md) contains a detailed description of each component - that's the best place to get started.
+The [specification](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/core/data_structures.md) contains a detailed description of each component - that's the best place to get started.
 
 To dig deeper, check out the [types package documentation](https://godoc.org/github.com/tendermint/tendermint/types).

docs/tendermint-core/consensus/README.md

@@ -23,7 +23,7 @@ explained in a forthcoming document.
 For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the
 block as the block size is big, i.e., they don't embed the block inside `Proposal` and
 `VoteMessage`. Instead, they reach agreement on the `BlockID` (see `BlockID` definition in
-[Blockchain](https://github.com/tendermint/tendermint/blob/master/spec/core/data_structures.md#blockid) section)
+[Blockchain](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/core/data_structures.md#blockid) section)
 that uniquely identifies each block. The block itself is
 disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a
 proposer first splitting a block into a number of block parts, that are then gossiped between

docs/tendermint-core/consensus/proposer-based-timestamps.md

@@ -51,8 +51,8 @@ useful for the protocols and applications built on top of Tendermint.
 
 The following protocols and application features require a reliable source of time:
 
-* Tendermint Light Clients [rely on correspondence between their known time](https://github.com/tendermint/tendermint/blob/master/spec/light-client/verification/README.md#definitions-1) and the block time for block verification.
-* Tendermint Evidence expiration is determined [either in terms of heights or in terms of time](https://github.com/tendermint/tendermint/blob/master/spec/consensus/evidence.md#verification).
+* Tendermint Light Clients [rely on correspondence between their known time](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/light-client/verification/README.md#definitions-1) and the block time for block verification.
+* Tendermint Evidence expiration is determined [either in terms of heights or in terms of time](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/consensus/evidence.md#verification).
 * Unbonding of staked assets in the Cosmos Hub [occurs after a period of 21
  days](https://github.com/cosmos/governance/blob/master/params-change/Staking.md#unbondingtime).
 * IBC packets can use either a [timestamp or a height to timeout packet
@@ -92,5 +92,5 @@ proposed by their peers to be valid either.
 
 ## See Also
 
-* [The PBTS specification](https://github.com/tendermint/tendermint/blob/master/spec/consensus/proposer-based-timestamp/README.md)
+* [The PBTS specification](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/consensus/proposer-based-timestamp/README.md)
  contains all of the details of the algorithm.

docs/tendermint-core/pex/README.md

@@ -166,8 +166,8 @@ current, past, and rate-of-change data to inform peer quality.
 While a PID trust metric has been implemented, it remains for future work
 to use it in the PEX.
 
-See the [trustmetric](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-006-trust-metric.md)
-and [trustmetric useage](https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-007-trust-metric-usage.md)
+See the [trustmetric](https://github.com/tendermint/tendermint/blob/v0.36.x/docs/architecture/adr-006-trust-metric.md)
+and [trustmetric useage](https://github.com/tendermint/tendermint/blob/v0.36.x/docs/architecture/adr-007-trust-metric-usage.md)
 architecture docs for more details.
 
 

docs/tendermint-core/rpc.md

@@ -8,7 +8,7 @@ The RPC documentation is hosted here:
 
 - [https://docs.tendermint.com/master/rpc/](https://docs.tendermint.com/master/rpc/)
 
-To update the documentation, edit the relevant `godoc` comments in the [rpc directory](https://github.com/tendermint/tendermint/tree/master/rpc).
+To update the documentation, edit the relevant `godoc` comments in the [rpc directory](https://github.com/tendermint/tendermint/blob/v0.36.x/rpc).
 
 If you are using Tendermint in-process, you will need to set the version to be displayed in the RPC.
 

docs/tendermint-core/using-tendermint.md

@@ -49,7 +49,7 @@ definition](https://github.com/tendermint/tendermint/blob/master/types/genesis.g
   chain IDs, you will have a bad time. The ChainID must be less than 50 symbols.
 - `initial_height`: Height at which Tendermint should begin. If a blockchain is conducting a network upgrade,
     starting from the stopped height brings uniqueness to previous heights.
-- `consensus_params` [spec](https://github.com/tendermint/tendermint/blob/master/spec/core/state.md#consensusparams)
+- `consensus_params` [spec](https://github.com/tendermint/tendermint/blob/v0.36.x/spec/core/state.md#consensusparams)
     - `block`
         - `max_bytes`: Max block size, in bytes.
         - `max_gas`: Max gas per block.
@@ -579,7 +579,7 @@ library will deny making connections to peers with the same IP address.
 ### Upgrading
 
 See the
-[UPGRADING.md](https://github.com/tendermint/tendermint/blob/master/UPGRADING.md)
+[UPGRADING.md](https://github.com/tendermint/tendermint/blob/v0.36.x/UPGRADING.md)
 guide. You may need to reset your chain between major breaking releases.
 Although, we expect Tendermint to have fewer breaking releases in the future
 (especially after 1.0 release).