Use `yes_votes` instead of `voting.threshold` when constructing `RawOrigin::Members` in pallet-collective

[liuchengxu]

substrate/frame/collective/src/lib.rs

Line 774 in 9d867b6

let origin = RawOrigin::Members(voting.threshold, seats).into();

Advantage

The drawback of using voting.threshold here is that each runtime can have its own threshold rule but this parameter now is not dynamic and hardcoded on the JS end, rendering the parameter of threshold submitted from the JS apps incorrect when a runtime uses a non-default value 1/2.

https://github.com/polkadot-js/apps/blob/777584eaad43c3ae6a46799e2fb7557221e6dc38/packages/apps-config/src/api/params/proposalThresholds.ts#L18-L23

Using yes_notes does not resolve the UI issue at all, but allows us to execute the call anyhow even the UI is not right. Say, a chain uses 3/4 for ExternalMajorityOrigin and the count of council members is 11, when a member clicks the Propose External button at https://polkadot.js.org/apps/, UI shows a threshold of 6 (the correct display is 9). 6 members can easily click the vote button to approve, 3 members can still approve this by using the extrinsics interface later. Eventually, the number of approvals becomes 9, the proposal should be approved, but due to the initial incorrect threshold is constructed in RawOrigin::Members(6, 11), the whole process simply fails, that does not make sense as we do have enough votes. Using yes_notes will help this.

Disadvantage

I can't think of any disadvantages, using yes_votes does not change the semantics and it's just more accurate IMO.

[liuchengxu]

CC @shawntabrizi