Add upgrade handler migration to enable send for restricted markers

[nullpointer0x00]

Summary

Currently, all restricted markers have been set to SendEnabled false. With the implementation of #1256 we can delete all items from the table. This will allow the send restrictions to be applied with the new handler.

Problem Definition

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[iramiller]

For this migration ... are the "send disabled" records within the bank module simply deleted? Or is there still a record for each token created ... this will have some impact on the management of that configuration within the marker module....

[nullpointer0x00]

As of right now, we are setting the send enabled to true(coin) or false(restricted) within from the marker module. With #1256 I set true for both with our current ensureSendEnabledStatus method. However, we could probably just delete them all and not have our marker module set them. The cosmos sdk has a parameter that indicates what it should default to if the coin is not found in the table. On both testnet and mainnet it is set to true. Therefore, if they all deleted from the table on upgrade IsSendEnabled will be true for the coin.

It would be nice to delete the ensureSendEnabledStatus method from the marker module and have the upgrade remove all entries. @SpicyLemon Thoughts?

[iramiller]

I feel like the best approach would be to remove all of those send disabled records, remove the ensure send disabled checks, and focus on the restrictions api style checking within the marker module itself for allowed/disallowed transfers. Not having the extra data in the bank module would be helpful here for reducing the gas costs slightly

[nullpointer0x00]

I agree. It is now removed and I updated the description of the ticket.

[SpicyLemon]

Just catching up on this.

I agree with removing ensureSendEnabledStatus.

And the only reason to keep all of those SendEnabled records around would be in the crazy off-chance that we change the DefaultSendEnabled param. I feel like that's pretty far outside the realm of possibilities, though, so it's okay to remove all those records. It'll save a little state, but each is just a key/value pair where the value is a single byte.

But since we need to either update them all to true or delete them, might as well just delete them.