chore: update documentation from cosmos-sdk/docs (#239)

docs/build/architecture/adr-033-protobuf-inter-module-comm.md

@@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether.
 
 * an alternative to keepers which can more easily lead to stable inter-module interfaces
 * proper inter-module OCAPs
-* improved module developer DevX, as commented on by several particpants on
+* improved module developer DevX, as commented on by several participants on
     [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q)
 * lays the groundwork for what can be a greatly simplified `app.go`
 * router can be setup to enforce atomic transactions for module-to-module calls

docs/build/building-modules/00-intro.md

@@ -63,6 +63,8 @@ While there are no definitive guidelines for writing modules, here are some impo
 The SDK provides a set of APIs that a module can implement, and a set of services that a module can use.
 Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. 
 
+Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes.
+
 Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
 
 ## Main Components of Cosmos SDK Modules

docs/build/migrations/02-upgrading.md

@@ -498,6 +498,16 @@ This change was made to allow legacy proposals to be compatible with server/v2.
 If you wish to migrate to server/v2, you should update your proposal handler to take in a `context.Context` and use services.
 On the other hand, if you wish to keep using baseapp, simply unwrap the sdk context in your proposal handler.
 
+#### `x/mint`
+
+The `x/mint` module has been updated to work with a mint function [`MintFn`](https://docs.cosmos.network/v0.52/build/modules/mint#mintfn).
+
+When using the default inflation calculation function and runtime, no change is required. The depinject configuration of mint automatically sets it if none is provided. However, when not using runtime, the mint function must be set in on the mint keeper:
+
+```diff
++ mintKeeper.SetMintFn(keeper.DefaultMintFn(types.DefaultInflationCalculationFn, stakingKeeper, mintKeeper))
+```
+
 #### `x/protocolpool`
 
 Introducing a new `x/protocolpool` module to handle community pool funds. Its store must be added while upgrading to v0.52.x.
@@ -532,6 +542,10 @@ storetypes.StoreUpgrades{
 Introducing `x/validate` a module that is solely used for registering default ante/post handlers and global tx validators when using runtime and runtime/v2. If you wish to set your custom ante/post handlers, no need to use this module.
 You can however always extend them by adding extra tx validators (see `x/validate` documentation).
 
+#### `tools/benchmark`
+
+Introducing [`tools/benchmark`](https://github.com/cosmos/cosmos-sdk/tree/main/tools/benchmark) a Cosmos SDK module for benchmarking your chain. It is a standalone module that can be added to your chain to stress test it. This module should NOT be added in a production environment.
+
 ## [v0.50.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.0-alpha.0)
 
 ### Migration to CometBFT (Part 2)

docs/learn/beginner/00-app-anatomy.md

@@ -59,7 +59,7 @@ In general, the core of the state-machine is defined in a file called `app.go`.
 
 The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts:
 
-* **Embeding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
+* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
     * `Runtime` wraps `baseapp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. Baseapp implements all the [ABCI methods](https://docs.cometbft.com/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers).
     * It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker).
 * [**An App Wiring configuration file**](../../build/building-apps/00-runtime.md) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed.

versioned_docs/version-0.52/build/architecture/adr-033-protobuf-inter-module-comm.md

@@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether.
 
 * an alternative to keepers which can more easily lead to stable inter-module interfaces
 * proper inter-module OCAPs
-* improved module developer DevX, as commented on by several particpants on
+* improved module developer DevX, as commented on by several participants on
     [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q)
 * lays the groundwork for what can be a greatly simplified `app.go`
 * router can be setup to enforce atomic transactions for module-to-module calls

versioned_docs/version-0.52/build/building-modules/00-intro.md

@@ -63,6 +63,8 @@ While there are no definitive guidelines for writing modules, here are some impo
 The SDK provides a set of APIs that a module can implement, and a set of services that a module can use.
 Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. 
 
+Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes.
+
 Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
 
 ## Main Components of Cosmos SDK Modules

versioned_docs/version-0.52/build/migrations/02-upgrading.md

@@ -455,6 +455,16 @@ This change was made to allow legacy proposals to be compatible with server/v2.
 If you wish to migrate to server/v2, you should update your proposal handler to take in a `context.Context` and use services.
 On the other hand, if you wish to keep using baseapp, simply unwrap the sdk context in your proposal handler.
 
+#### `x/mint`
+
+The `x/mint` module has been updated to work with a mint function [`MintFn`](https://docs.cosmos.network/v0.52/build/modules/mint#mintfn).
+
+When using the default inflation calculation function and runtime, no change is required. The depinject configuration of mint automatically sets it if none is provided. However, when not using runtime, the mint function must be set in on the mint keeper:
+
+```diff
++ mintKeeper.SetMintFn(keeper.DefaultMintFn(types.DefaultInflationCalculationFn, stakingKeeper, mintKeeper))
+```
+
 #### `x/protocolpool`
 
 Introducing a new `x/protocolpool` module to handle community pool funds. Its store must be added while upgrading to v0.52.x.
@@ -488,3 +498,7 @@ storetypes.StoreUpgrades{
 
 Introducing `x/validate` a module that is solely used for registering default ante/post handlers and global tx validators when using runtime and runtime/v2. If you wish to set your custom ante/post handlers, no need to use this module.
 You can however always extend them by adding extra tx validators (see `x/validate` documentation).
+
+#### `tools/benchmark`
+
+Introducing [`tools/benchmark`](https://github.com/cosmos/cosmos-sdk/tree/main/tools/benchmark) a Cosmos SDK module for benchmarking your chain. It is a standalone module that can be added to your chain to stress test it. This module should NOT be added in a production environment.

versioned_docs/version-0.52/learn/beginner/00-app-anatomy.md

@@ -59,7 +59,7 @@ In general, the core of the state-machine is defined in a file called `app.go`.
 
 The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts:
 
-* **Embeding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
+* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
     * `Runtime` wraps `baseapp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. Baseapp implements all the [ABCI methods](https://docs.cometbft.com/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers).
     * It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker).
 * [**An App Wiring configuration file**](../../build/building-apps/00-runtime.md) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed.