Switch pallet-bioauth authorities to WeakBoundedVec and enable generate_storage_info

[dmitrylavrenov]

Closes #187

[MOZGIII]

Why can't we just make the AuthTicketNonce type the WeakBoundedVec instead of Vec, and leave it in the pallet?

[dmitrylavrenov]

Why can't we just make the AuthTicketNonce type the WeakBoundedVec instead of Vec, and leave it in the pallet?

In case we use AuthTicketNonce as WeakBoundedVec it provides getting an error due to genesis_config requires all fields be serialized and deserialized.

pub consumed_auth_ticket_nonces: Vec<AuthTicketNonce<T>>, the trait Serialize is not implemented for WeakBoundedVec<u8, <T as pallet::Config>::MaxAuthTicketNonce

The task is to define a type for AuthTickenNonce that will have a limited size and be serialized and deserialized. That's why for now I exposed it to the runtime level where it can be implemented.

According the fact that [u8; 32] is serialized and deserialized we can use it at pallet level easly.

[MOZGIII]

I think this is ultimately a good time to take into account the refactoring of our nonces system.
Currently, they are just integers under the hood, but what we really want, I think, is a salted hash of the said value to make it look more unique. I'd like to hear your thoughts on this though. If we go with this - then we can switch to constant-size arrays.
Alternatively, if we decide to go without obscuring the nonce values, we can start representing them via the actual integers - i.e. u128 vs [u8; N].

[dmitrylavrenov]

I think this is ultimately a good time to take into account the refactoring of our nonces system.
Currently, they are just integers under the hood, but what we really want, I think, is a salted hash of the said value to make it look more unique. I'd like to hear your thoughts on this though. If we go with this - then we can switch to constant-size arrays.
Alternatively, if we decide to go without obscuring the nonce values, we can start representing them via the actual integers - i.e. u128 vs [u8; N].

In terms of nonces, I like to use it as a cryptographic object to make it more unique. A salted hash os one of them as well. For example for now we can use SHA256 to generate nonces from salt. 256 bits hash is 32 bytes. Therefore, [u8; 32] can be used for now. What do you think?

[MOZGIII]

I'd like to discuss the pros and cons of going with obscured vs plain nonce; regarding the hash function itself - we probably should discuss it later, but I think we need to go with something like keccak, rather than sha2...

[MOZGIII]

See comments

[MOZGIII]

I think this is ready to merge, let's do it?

[dmitrylavrenov]

I think this is ready to merge, let's do it?

Just doing it.