AccAddress caching causes incorrect bech32 prefixes

[KyleMoser]

Summary of Bug

AccAddress caching (the caches in types/address.go, including accAddrCache) cause unexpected behavior when printing bech32 account addresses on clients. For example, it may print an address prefixed with "cosmos" when you expected "osmo". An example client that experiences this buggy behavior is the go relayer.

Furthermore, you cannot always work around this behavior since many internal SDK functions call .String() on the AccAddress. For example, this is the case during Feegranting.

Version

Every version I could find

Steps to Reproduce

It's important to note that the bug requires using the same mnemonic on multiple chains.

1. Set the SDK account prefixes to "cosmos"
2. Print out an AccAddress.String() and it will start with "cosmos"
3. Set the SDK account prefixes to "osmo"
4. Print out the same AccAddress.String() and it will still start with "cosmos"

There are two plausible ways I can think of to fix this bug.

1. Add a function to the SDK that allows disabling the account caches, e.g. SetAccountCacheEnabled(bool).
2. Any time the bech32 prefixes are reset (e.g. SetBech32PrefixForAccount is called) clear the caches.

I think fix 1 is a much better solution as it gives clients more control, I am working on a PR to address this bug.

[tac0turtle]

thanks for opening this issue, as part of the q1 work we will be removing this global in favour of interface to decode and encode that sets the desired prefix.

This will most likely land in 0.48, so in 0.47 we can think of accepting a pr to fix the issue for the go relayer