Prop 556: Osmosis v16 Magnesium Upgrade

This is a proposal to do a software upgrade to the v16.0.0 software tag of the Osmosis codebase on block height 10517000, which is estimated to occur on Thursday July 13th, UTC 16:00. Block times have high variance, so please monitor the chain for more precise time estimates.

# Upgrade Features
This upgrade adds the following features:

## Supercharged Liquidity Module
Introduces a game-changing pool model that enhances capital efficiency in Osmosis by allowing a position to be concentrated around a finite token ratio rather than evenly across an infinite range as in classic pools or providing a bias around a set ratio point as with Stableswap pools.

The Supercharged liquidity module, x/concentratedliquidity, is deployed under a Business Source License 1.1. This license limits the use of the module code in a commercial or production setting for two years at which point it converts to a standard GNU GPL v.2 or later license in use in Osmosis modules.
Osmosis Governance can accelerate this conversion of license or grant exemptions through a text proposal.
This restriction allows cross-chain interaction with Osmosis' Supercharged Liquidity pools through mechanisms such as Inter Chain Accounts and Packet Forwarding Middleware smart contracts but limits the location at which liquidity is deployed in these pools to the Osmosis chain.

## CosmWasm Pool Module
Enables the creation and management of liquidity pools backed by CosmWasm smart contracts that are fully integrated within the existing pool structure.
This allows new experimental pools types to be implemented without a software upgrade and quickly iterated upon. An example of a new pool type that will be proposed is the Transmuter pool type.

## ProtoRev Module Upgrades
Now uses hooks instead of parsing messages, leading to more transaction types that trigger ProtoRev.
Modifies the payment schedule for the dev account from weekly to after every trade.

## Quality of Life Changes
Exit Fee disabled on pool creation
Actions Proposal 429 by preventing the creation of new pools with an Exit Fee.

Multi-Asset Fee Whitelisting
Allows a single governance proposal to whitelist multiple fee tokens that are permitted for use as transaction fees at a time. This will enable the bulk addition of fee tokens to Osmosis and enable users to pay for their first transaction in most denominations.

Route Splitting Impact protection enabled
Allows multiple swap messages provided across multiple routes to be linked together while keeping the price impact protection setting from the overall Swap message. This optimizes swaps by allowing interfaces to route through multiple pools to obtain a lower slippage than using one pool alone.

SwapFee parameters changed to SpreadFactor
Osmosis has listed pools as having a "swap fee" since launch. In an AMM this acts identically to a spread on an order book in which a position trades around. With the introduction of Supercharged Liquidity, this becomes more apparent due to the variable positions and so all instances of a Swap Fee are renamed to a Spread Factor.

See the Full Change Log for more API Breaking, State Breaking and other miscellaneous changes.

# Getting Prepared for the Upgrade
To build the binary, be sure to install golang 1.20.

As always, we recommend validators utilize 64GB of RAM. Since state migration is relatively negligible in this upgrade, it is possible to get away with less, but still not recommended. If you are unable to have 64GB of RAM, at a minimum have a total of 64GB of swap set to prevent out of memory errors.

If using Cosmovisor, manually build & copy the osmosisd binary to /cosmovisor/upgrades/v16/bin/.

If not using Cosmovisor, wait for your node to halt at the upgrade height, then install and run the v16.0.0 binary.

# Details of Upgrade Time
The proposal targets the upgrade proposal block to be 10517000, anticipated to be on Thursday July 13th, UTC 16:00. Note that block times have high variance, so keep monitoring the time. See countdown here.

The upgrade is anticipated to take approx 30 minutes, during which time, there will not be any on-chain activity on the network.

In the event of an issue at upgrade time, we should coordinate via the validators channel in Discord to come to a quick emergency consensus and mitigate any further issues.