Olympia proposals schema, mappings and tests

[Lezek123]

Draft PR based on #2345 in order to include membership and working groups mappings.

Input schema introduced in commit: 62b7310

Future relationship with Council mappings:

It's not yet exactly clear how the Council module mappings will affect this input schema.
For example, assuming we'll have an entity representing either current or past council member:

type CouncilMember @entity {
	# ...
}

We might want to switch the relationship in ProposalVoteEvent from Membership to CouncilMember.

Otherwise we may want to have a relationship between CouncilTerm / CouncilCadency and ProposalVoteEvent instead of ProposalVoteEvent.votingRound to easier connect proposal votes with council terms.

We may also need some other relationships between CouncilCadency and proposals to support displaying lists like:

Part of Pioneer's Council wireframes

Proposal parameters:

Since all proposals parameters like:

• voting period,
• grace period,
• approval quorum percentage,
• approval threshold percentage,
• slashing quorum percentage,
• slashing threshold percentage,
• required stake,
• constitutionality

are exposed by the runtime through proposalCodex module constants, ie.:

• api.consts.proposalsCodex.amendConstitutionProposalParameters
• api.consts.proposalsCodex.cancelWorkingGroupLeadOpeningProposalParameters
• ...

I didn't include those in the mappings and assumed the frontend applications (like Pioneer v2) will use @polkadot/api in order to retrieve those values.

This means that values that depend on them will need to also be calculated on the frontend, for example:

if (proposal.status.__typename === 'ProposalStatusGrace') {
	const executesAtBlock = proposal.exactExecutionBlock || (proposal.createdInEvent.blockNumber + gracePeriodByProposalType(proposal.details.__typename))
}

Proposal status history:

In order to display proposal status history like:

With the current schema we can use proposal.createdInEvent for initial status, proposal.proposalStatusUpdates for or the "intermediate" statuses and proposal.status for the current (possibly final) status.

For example:

Created / Deciding (blocknumber, timestamp etc. comes from proposal.createdInEvent)
=>
Dormant (proposal.proposalStatusUpdates[0])
=>
Deciding (proposal.proposalStatusUpdates[1])
=>
Dormant (proposal.proposalStatusUpdates[2])
=>
Deciding (proposal.proposalStatusUpdates[3])
=>
Gracing (proposal.proposalStatusUpdates[4])
=>
ExecutionFailed (proposal.status + event data from, in this case, proposal.status.proposalExecutedEvent)

Searching and filtering by "endedAt" time/block

To faciliate filtering by ending time:

I added statusSetAtBlock and statusSetAtTime fields.
Otherwise we would need a spearate filter for each possible related event type in proposal status variants.
Also filtering by variant relations is not currently supported by Hydra and even if supported in the future, it's not clear how deeply into the schema this type of filtering would be able to reach.

In order to faciliate searching by "keywords" I also added fullTextSearch queries for proposal title and text.

History of aprovals:

Currently the votes can be split by votingRound (part of ProposalVotedEvent), which will be incremented after each approval for proposals with consitutionality > 1 (as described in the input schema) in order to display proposal approvals history data on separate tabs:

In the future this may be replaced with relationship between ProposalVoteEvent and CouncilTerm / CouncilCandidacy. (see: Future relationship with Council mappings)

Pioneer wireframes inconsistencies:

I noticed a few incosistencies in the Pioneer v2 Proposals wireframes:

• Proposal discussion mode:
  
  As can be seen on the screen above, the proposal discussion mode and whitelist is set during proposal creation, while in the current runtime implementation the discussion thread always begins in Open mode, which can then be switched by either proposal creator or an active council member. I didn't notice the action of updating the proposal discussion thread represented in any of the wireframes.

• Funding request proposal creation:
  
  While the runtime FundingProposal can have multiple destinations specified, the Pioneer designs incidate that only one destination is supported.

• Lead opening proposal creation / details:
  
  I think the metadata provided for lead opening proposal should be the same as for any other opening, which means it would also include applicationDetails applicationFormQuestions etc. This doesn't seem to be the case in the current lead opening proposal creation form design.

[Lezek123]

Merged to #2547 for convinience