backport 0.42.x: Fix IBC doc links (#9210)

closes: #9180

docs/ibc/custom.md

@@ -31,7 +31,7 @@ module correctly.
 ### Implement `IBCModule` Interface and callbacks
 
 The Cosmos SDK expects all IBC modules to implement the [`IBCModule`
-interface](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/05-port/types/module.go). This
+interface](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/05-port/types/module.go). This
 interface contains all of the callbacks IBC expects modules to implement. This section will describe
 the callbacks that are called during channel handshake execution.
 
@@ -209,7 +209,7 @@ channel, as well as how they will encode/decode it. This process is not specifie
 to each application module to determine how to implement this agreement. However, for most
 applications this will happen as a version negotiation during the channel handshake. While more
 complex version negotiation is possible to implement inside the channel opening handshake, a very
-simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc-transfer/module.go).
+simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/applications/transfer/module.go).
 
 Thus, a module must define its a custom packet data structure, along with a well-defined way to
 encode and decode it to and from `[]byte`.
@@ -336,7 +336,7 @@ not want the packet processing to revert. Instead, we may want to encode this fa
 acknowledgement and finish processing the packet. This will ensure the packet cannot be replayed,
 and will also allow the sender module to potentially remediate the situation upon receiving the
 acknowledgement. An example of this technique is in the `ibc-transfer` module's
-[`OnRecvPacket`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc-transfer/module.go).
+[`OnRecvPacket`](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/applications/transfer/module.go).
 :::
 
 ### Acknowledgements
@@ -358,9 +358,9 @@ Thus, modules must agree on how to encode/decode acknowledgements. The process o
 acknowledgement struct along with encoding and decoding it, is very similar to the packet data
 example above. [ICS 04](https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics#acknowledgement-envelope)
 specifies a recommended format for acknowledgements. This acknowledgement type can be imported from
-[channel types](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel/types).
+[channel types](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/04-channel/types).
 
-While modules may choose arbitrary acknowledgement structs, a default acknowledgement types is provided by IBC [here](https://github.com/cosmos/cosmos-sdk/blob/master/proto/ibc/core/channel/v1/channel.proto):
+While modules may choose arbitrary acknowledgement structs, a default acknowledgement types is provided by IBC [here](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/proto/ibc/core/channel/v1/channel.proto):
 
 ```proto
 // Acknowledgement is the recommended acknowledgement format to be used by
@@ -455,13 +455,13 @@ which implements everything discussed above.
 Here are the useful parts of the module to look at:
 
 [Binding to transfer
-port](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/genesis.go)
+port](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/applications/transfer/genesis.go)
 
 [Sending transfer
-packets](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/keeper/relay.go)
+packets](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/applications/transfer/keeper/relay.go)
 
 [Implementing IBC
-callbacks](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/module.go)
+callbacks](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/applications/transfer/module.go)
 
 ## Next {hide}
 

docs/ibc/integration.md

@@ -7,7 +7,7 @@ order: 2
 Learn how to integrate IBC to your application and send data packets to other chains. {synopsis}
 
 This document outlines the required steps to integrate and configure the [IBC
-module](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc) to your Cosmos SDK application and
+module](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc) to your Cosmos SDK application and
 send fungible token transfers to other chains.
 
 ## Integrating the IBC module
@@ -25,7 +25,7 @@ Integrating the IBC module to your SDK-based application is straighforward. The
 ### Module `BasicManager` and `ModuleAccount` permissions
 
 The first step is to add the following modules to the `BasicManager`: `x/capability`, `x/ibc`,
-`x/evidence` and `x/ibc-transfer`. After that, we need to grant `Minter` and `Burner` permissions to
+`x/evidence` and `x/ibc/applications/transfer`. After that, we need to grant `Minter` and `Burner` permissions to
 the `ibc-transfer` `ModuleAccount` to mint and burn relayed tokens.
 
 ```go
@@ -75,7 +75,7 @@ type App struct {
 ### Configure the `Keepers`
 
 During initialization, besides initializing the IBC `Keepers` (for the  `x/ibc`, and
-`x/ibc-transfer` modules), we need to grant specific capabilities through the capability module
+`x/ibc/applications/transfer` modules), we need to grant specific capabilities through the capability module
 `ScopedKeepers` so that we can authenticate the object-capability permissions for each of the IBC
 channels.
 
@@ -120,7 +120,7 @@ IBC needs to know which module is bound to which port so that it can route packe
 appropriate module and call the appropriate callbacks. The port to module name mapping is handled by
 IBC's port `Keeper`. However, the mapping from module name to the relevant callbacks is accomplished
 by the port
-[`Router`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc//core/05-port/types/router.go) on the
+[`Router`](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc//core/05-port/types/router.go) on the
 IBC module.
 
 Adding the module routes allows the IBC handler to call the appropriate callback when processing a
@@ -204,7 +204,7 @@ past historical info at any given height in order to verify the light client `Co
 connection handhake.
 
 The IBC module also has
-[`BeginBlock`](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc/core/02-client/abci.go) logic as
+[`BeginBlock`](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/02-client/abci.go) logic as
 well. This is optional as it is only required if your application uses the [localhost
 client](https://github.com/cosmos/ics/blob/master/spec/ics-009-loopback-client) to connect two
 different modules from the same chain.
@@ -245,7 +245,7 @@ func NewApp(...args) *App {
 
 That's it! You have now wired up the IBC module and are now able to send fungible tokens across
 different chains. If you want to have a broader view of the changes take a look into the SDK's
-[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/master/simapp/app.go).
+[`SimApp`](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/simapp/app.go).
 
 ## Next {hide}
 

docs/ibc/overview.md

@@ -26,19 +26,19 @@ module correctly.
 
 ## Components Overview
 
-### [Clients](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/02-client)
+### [Clients](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/02-client)
 
 IBC Clients are light clients (identified by a unique client-id) that track the consensus states of
 other blockchains, along with the proof spec necessary to properly verify proofs against the
 client's consensus state. A client may be associated with any number of connections to multiple
 chains. The supported IBC clients are:
 
-* [Solo Machine light client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/06-solomachine): devices such as phones, browsers, or laptops.
-* [Tendermint light client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/07-tendermint): The default for SDK-based chains,
-* [Localhost (loopback) client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/09-localhost): Useful for
+* [Solo Machine light client](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/light-clients/06-solomachine): devices such as phones, browsers, or laptops.
+* [Tendermint light client](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/light-clients/07-tendermint): The default for SDK-based chains,
+* [Localhost (loopback) client](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/light-clients/09-localhost): Useful for
 testing, simulation and relaying packets to modules on the same application.
 
-### [Connections](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/03-connection)
+### [Connections](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/03-connection)
 
 Connections encapsulate two `ConnectionEnd` objects on two seperate blockchains. Each
 `ConnectionEnd` is associated with a client of the other blockchain (ie counterparty blockchain).
@@ -47,7 +47,7 @@ correct for their respective counterparties. Connections, once established, are
 facilitation all cross-chain verification of IBC state. A connection may be associated with any
 number of channels.
 
-### [Proofs](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/23-commitment) and [Paths](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/24-host)
+### [Proofs](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/23-commitment) and [Paths](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/24-host)
 
 In IBC, blockchains do not directly pass messages to each other over the network. Instead, to
 communicate, a blockchain will commit some state to a specifically defined path reserved for a
@@ -82,7 +82,7 @@ IBC will correctly route all packets to the relevant module using the (channelID
 IBC module may also communicate with another IBC module over multiple ports, with each
 `(portID<->portID)` packet stream being sent on a different unique channel.
 
-### [Ports](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/05-port)
+### [Ports](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/05-port)
 
 An IBC module may bind to any number of ports. Each port must be identified by a unique `portID`.
 Since IBC is designed to be secure with mutually-distrusted modules operating on the same ledger,
@@ -91,7 +91,7 @@ binding a port will return a dynamic object capability. In order to take action
 handler. This prevents a malicious module from opening channels with ports it does not own. Thus,
 IBC modules are responsible for claiming the capability that is returned on `BindPort`.
 
-### [Channels](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel)
+### [Channels](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/04-channel)
 
 An IBC channel can be established between 2 IBC ports. Currently, a port is exclusively owned by a
 single module. IBC packets are sent over channels. Just as IP packets contain the destination IP
@@ -126,7 +126,7 @@ that the module **must** claim so that they can pass in a capability to authenti
 like sending packets. The channel capability is passed into the callback on the first parts of the
 handshake; either `OnChanOpenInit` on the initializing chain or `OnChanOpenTry` on the other chain.
 
-### [Packets](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel)
+### [Packets](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/04-channel)
 
 Modules communicate with each other by sending packets over IBC channels. As mentioned above, all
 IBC packets contain the destination `portID` and `channelID` along with the source `portID` and
@@ -141,7 +141,7 @@ Thus, packet data is completely opaque to IBC handlers. It is incumbent on a sen
 their application-specific packet information into the `Data` field of packets, and the receiver
 module to decode that `Data` back to the original application data.
 
-### [Receipts and Timeouts](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel)
+### [Receipts and Timeouts](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/04-channel)
 
 Since IBC works over a distributed network and relies on potentially faulty relayers to relay messages between ledgers, 
 IBC must handle the case where a packet does not get sent to its destination in a timely manner or at all. Thus, packets must 
@@ -157,7 +157,7 @@ In the UNORDERED case, packets may be received in any order. Thus, IBC will writ
 
 For this reason, most modules should use UNORDERED channels as they require less liveness guarantees to function effectively for users of that channel.
 
-### [Acknowledgements](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel)
+### [Acknowledgements](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/04-channel)
 
 Modules may also choose to write application-specific acknowledgements upon processing a packet. This may either be done synchronously on `OnRecvPacket`, if the module processes packets as soon as they are received from IBC module. Or they may be done asynchronously if module processes packets at some later point after receiving the packet.
 

docs/ibc/relayer.md

@@ -14,7 +14,7 @@ order: 4
 Events are emitted for every transaction processed by the base application to indicate the execution
 of some logic clients may want to be aware of. This is extremely useful when relaying IBC packets.
 Any message that uses IBC will emit events for the corresponding TAO logic executed as defined in
-the [IBC events spec](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/spec/06_events.md).
+the [IBC events spec](https://github.com/cosmos/cosmos-sdk/tree/release/v0.42.x/x/ibc/core/spec/06_events.md).
 
 In the SDK, it can be assumed that for every message there is an event emitted with the type `message`,
 attribute key `action`, and an attribute value representing the type of message sent