Identity pallet improvements

[georgepisaltu]

This PR is a follow up to #1661

• rename the simple module to legacy
• fix benchmarks to disregard the number of additional fields
• change the storage deposits to charge per encoded byte of the identity information instance, removing the need for fn additional(&self) -> usize in IdentityInformationProvider
• add an extrinsic to rejig deposits to account for the change above
• ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now
• remove IdentityFields from the set_fields extrinsic signature, as per this discussion

ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now

Not sure this is needed anymore. If the new deposits are higher than what is currently on chain and users don't have enough funds to reserve what is needed, the extrinisc fails and they're basically grandfathered and frozen until they add more funds and/or make a change to their identity. This behavior seems fine to me. Original idea here.

add an extrinsic to rejig deposits to account for the change above

This was initially implemented but now removed from this PR in favor of the implementation detailed here.

[joepetrowski]

This seems very large, I imagine even 1 kB would be enough. Maybe 5 kB?

[georgepisaltu]

I just took the constant from the preimage pallet. Here is a more informed view: a "full" IdentityInfo without any entries in additional has an encoded size of 253 bytes. Each entry in additional is then worth at most 66 bytes, depending on the values chosen for the key and value, since they're Data. With the current values for T::MaxAdditionalFields of 100, that brings us to at most 253 + 66 * 100 or ~6.7 KiB maximum encoded size for any value currently in storage. Considering this, I set it to 7 KiB now and we can lower it later if we wish to do so.

[joepetrowski]

Yeah, that sounds good. The preimage pallet is meant to store data such that you can remove it if the system hasn't requested it. Setting an identity clears any judgements, so we don't really expect people to remove their data once they have set it. Of course the byte fee accounts for it, but it seems more flexible to just have a field meant to take a hash that can be hosted elsewhere. Then, people could actually use the preimage pallet if it needed to be on-chain, or some off-chain hosting service if the reader of the Identity Info knew where to look for it.

[georgepisaltu]

I also added some more checked arithmetic where applicable, just to be consistent.

[georgepisaltu]

I just took the constant from the preimage pallet. Here is a more informed view: a "full" IdentityInfo without any entries in additional has an encoded size of 253 bytes. Each entry in additional is then worth at most 66 bytes, depending on the values chosen for the key and value, since they're Data. With the current values for T::MaxAdditionalFields of 100, that brings us to at most 253 + 66 * 100 or ~6.7 KiB maximum encoded size for any value currently in storage. Considering this, I set it to 7 KiB now and we can lower it later if we wish to do so.

[georgepisaltu]

remove IdentityFields from the set_fields extrinsic signature, as per #1661 (comment)

The set_fields extrinisc now accepts the underlying numerical representation as the input. This is currently u64 for us and will probably continue to be since there's no reason to change it. This change requires no migration now, since it's the same u64 in storage as before, but if the underlying numeric type changes when we move away from the legacy impls, it will require a migration.

[joepetrowski]

Should also get review from @bkchr and/or @ggwpez before merging though