Document different mapping options

[ericbutz]

Requested update to Dev hub:

• We may want a FIP that would allow a FIO public key to not receive tokens. Meaning the blockchain would reject an attempt to send to this public key. It's an edge case, for sure, but here's the scenario: Exchange sets up deposits@exchange for sending out all FIO Requests and each request has individual public addresses for those deposits. If a user sends FIO directly to deposits@exchange, a FIO mapping that can't be removed or changed or it will break the encryption process, they won't know who to send those tokens to and it creates a support headache for them. If, instead, the chain just refused to accept the tokens on that public key, the problem is avoided.
• Wallets: bad idea to ever change the FIO public mapping. It breaks the default encryption scheme by using the wrong public key.
• Exchanges: it can make sense to to allow for mapping changes because there may be two different security models (wallets) in place. One controls individual user account private keys, one controls the FIO side of things (creating mappings, sending FIO requests, etc). In this scenario, they don't want the deposit accounts to own the FIO responsibilities for user1@exchange because then they would need that FIO private key for managing anything related to that FIO public address. As long as they never send a FIO request from user1@exchange (because the lookup of that public key would not map correctly to the on chain actor account for that encrypted request), it should work.

@eric Butz [Dapix] that an okay summary of what we learned on the call? If so, can you update the docs appropriately? I think this nuance is a really important one (Don't change the FIO mapping! ...unless it's okay to do so) for our integration partners to understand because if they don't FIO functionality breaks.

[ericbutz]

See: https://gist.github.com/sonhnguyenn/601173fda4255355c825f02f40b81096