Change the way SPO votes are counted

[williamdemeo]

This issue reflects the corresponding cardano-ledger issue, and the description below is nearly identical to the description given there.

It has been brought up by a number of community members that the way we currently compute SPO votes is not what everyone expected.
Current implementation is such that for HardForkInitiation behavior is exactly the same as for DReps, however for the other three governance actions, that SPOs can vote on, behavior is different for SPOs that did not vote. In other words for these three governance action types:

• NoConfidence
• UpdateCommittee
• ParameterUpdate (when it includes updates to parameter belonging to the security group)

the default vote counted for SPOs that didn't vote is Abstain, instead of No. The default vote of No is the behavior for DReps, while for SPOs it is default only when HardForkInitiation is proposed.

Current behavior is specified in the following lines of the spec:

formal-ledger-specifications/src/Ledger/Ratify.lagda

Lines 378 to 380 in 762d3f4

	actualSPOVotes : GovAction → VDeleg ⇀ Vote
	actualSPOVotes (TriggerHF _) = roleVotes SPO ∪ˡ constMap spos Vote.no
	actualSPOVotes _ = roleVotes SPO ∪ˡ constMap spos Vote.abstain

The corresponding implementation is here.

This led to some concerns about inclusion of SPOs in future parameter updates, which is why many have suggested we mimic the behavior of DReps exactly. However, defaulting of SPOs to vote No raises other concerns. In particular there is a danger that sensible proposals could be inadvertently blocked by SPOs that are not active enough. Inactivity could be potentially blamed either on indifference or issues with legality for some SPOs.

In order to solve this conundrum we made it the topic of Ledger Working Group Meeting #4 and had a very productive discussion with some community members and came up with the following ingenious solution:

Everyone agreed right off the bat that a mechanism for allowing SPOs to choose whether they wanted to default to Abstain instead of No would solve the problem. However making a change to PoolParams is impossible without a new era. Also, whenever the issue of customizing PoolParams has surfaced during Conway development, it was apparent that such a change would be too ambitious and result in extensive delay to Conway delivery. This has to do with the fact that PoolParams is not a type family yet. Since adding a custom field to the PoolParams with an optional default vote was not an option, we almost discarded this idea. It was then that Martin Lang of ATADA Stake Pool proposed an interesting and unexpected solution: we could achieve the ability for SPOs to specify a default vote if we choose to mimic the default delegation of ppRewardAccount that is specified in the PoolParams.

To be more specific the solution to this problem is as follows:

1. Change the default vote for SPOs to No from Abstain for all of the three proposals in question.
2. Check whether SPO's reward address is delegated to the predefined AlwaysNoConfidence DRep and count default vote as Yes only on NoConfidence proposals for that SPO.
3. Check whether SPO's reward address is delegated to predefined AlwaysAbstain DRep and count default vote as Abstain for that SPO on all three: NoConfidence, UpdateCommitee and ParameterUpdate proposals.

This is not a terribly complicated logic to implement, which means that we can almost certainly take care of in time for the protocol version 10.0, i.e. the intra-era hard fork, a.k.a Chang+1.

[WhatisRT]

Reopening because the PR had a bug