[REFACTORING] Upgrade to polkadot-v0.9.40 and rewrite-optimise pallet_Roles

[ndkazu]

Motivation

Now that the web3 grant has been completed, and before adding new functionalities, we need to clean-up and optimise our code.
This is no small task, so we need good planning.

Suggested Solution
Feel free to add to, adjust this planning. This is a preliminary issue, an detailed content of the task should be discussed/established with all team member before any coding.

1. Upgrade to polkadot-v0.9.40:

• We can start from the substrate node template.

2. Upgrade Roles pallet:

• Remove sudo operations
• Remove cargo clippy warnings
• Rewrite tests
• Complete pallet benchmarking

3. Upgrade Housing Fund pallet
4. Upgrade Nft-pallet
5. Upgrade Onboarding pallet

To be continued...

[ndkazu]

Step 1 - Rewrite Pallet-Roles

• Reconsider each role's meaning in Fair Square environment (this might lead to the addition or removal of some roles)
• Seller, Notary & Servicer roles should be attributed through a governance system.
  • Add a Background-check Council for the pallet role
  • Connect council Referendum start to permission roles requests
  • Add voting extrinsic for new council
  • Ensure execution of the proper calls at the end
• Correct types.rs & functions.rs to remove Clippy warnings
• Add a Boolean in the runtime to activate/deactivate the governance system for Seller, Notary, & Servicer roles (Test or production environment)
• Update the chain_spec file with all the different genesis (use main_branch as a model)
• Write the new tests
• Write proper pallet benchmarking
• Update the documentation

Users should be able to have several roles: Sensitives roles attribution happens through governance.

[ndkazu]

Pallet roles remarks:

• From a backend stance, the storage RequestedRoles is redundant and not necessary, as we already have Approval waiting lists storages for each role that requires it ➡ Ruperposed this storage for the governance system
• We don't need Representatives at genesy: They are not connected to any asset, and are not used for testing ➡no real use for the function init_representatives in pallet_roles.

[ndkazu]

Identity details and Council

Motivation
In both pallets where council is used, we need informations for the council to make an informed vote. In the vote pallet, we solved this problem by adding Dummy parameters. This is not good enough.

Suggestion

• Ideal solution would to connect to an external ID protocol such as Litentry or Kilt, for example
• The suggested solution is to use the identity pallet, and requires from reqesting users links to their Litentry/Kilt ID. Registrars would are the council members (incitivised to check suscribers ID and give a judgement before voting). Another advantage in this system is that because of the judgement, the suscriber gets a feedback on why he was accepted/rejected by the council.