Clarify what VoteVariation types 2.0 supports, and make test cases for them

[danwallach]

Allowed via range proofs

[JohnLCaron]

Range proofs enable cumulative voting. To do so:

1. Section 3.3, 3.3,1: selection text must be generalized from (0, 1) to (0, limit)

The code to be changed:

1. ManifestInputValidation allows ContestDecription.voteVariation == cumulative
2. Range proofs are substituted for disjunctive proofs in Encryptor.encryptSelection(), if cumulative
3. ContestData over_votes might want to record the selection vote amount, instead of assuming == 1
4. Add tests

[danwallach]

Cumulative voting: a voter has a fixed number of votes ( $t$, for now), and can then hand them out to as few or as many candidates as they want. We'll need a range proof for each candidate, saying that they have $[0,t]$ votes, and then we have a range proof for the sum of all the candidates that it, as well, is in $[0,t]$.

Pick 1-of-n: the individual proofs are all zero-or-one and the sum proof is zero-or-one.

Pick k-of-n: you can vote for as many as $k$ choices. All the individual proofs are zero-or-one, and the sum proof is a range $[0,k]$.

Approval voting: You don't need the sum proof any more, since you can vote for as many or as few as you want, but you need zero-or-one proofs for each candidate.

Of course, every zero-or-one disjunctive proof can and should be implemented with a range proof. Once we're happy with that, we can probably remove the disjunctive proofs entirely.

[JohnLCaron]

From spec 1.9, p 10:

"For some voting methods such as cumulative voting, Borda count,
and a variety of cardinal voting methods like score voting and STAR-voting, it can be necessary to
encrypt other small, positive integers."

Need to clarify what VoteVAriation types we are supporting, and get some test cases for them

/**
     * Enumeration for contest algorithm or rules in the contest.
     * @see [Civics Common Standard Data Specification](https://developers.google.com/elections-data/reference/vote-variation)
     */
    enum class VoteVariationType {
        /** Each voter can select up to one option. */
        one_of_m,

        /** Approval voting, where each voter can select as many options as desired. */
        approval,

        /**
         * Borda count, where each voter can rank the options, and the rankings are assigned point
         * values.
         */
        borda,

        /** Cumulative voting, where each voter can distribute their vote to up to N options. */
        cumulative,

        /** A 1-of-m method where the winner needs more than 50% of the vote to be elected. */
        majority,

        /** A method where each voter can select up to N options. */
        n_of_m,

        /**
         * A 1-of-m method where the option with the most votes is elected, regardless of whether
         * the option has more than 50% of the vote.
         */
        plurality,

        /**
         * A proportional representation method, which is any system that elects winners in
         * proportion to the total vote. For the single transferable vote (STV) method, use rcv
         * instead.
         */
        proportional,

        /** Range voting, where each voter can select a score for each option. */
        range,

        /**
         * Ranked choice voting (RCV), where each voter can rank the options, and the ballots are
         * counted in rounds. Also known as instant-runoff voting (IRV) and the single transferable
         * vote (STV).
         */
        rcv,

        /**
         * A 1-of-m method where the winner needs more than some predetermined fraction of the vote
         * to be elected, and where the fraction is more than 50%. For example, the winner might
         * need three-fifths or two-thirds of the vote.
         */
        super_majority,

        /**
         * The vote variation is a type that isn't included in this enumeration. If used, provide
         * the item's custom type in an OtherType element.
         */
        other
    }

[JohnLCaron]

Spec 2.0.0 Section 3.1.3 . p 17 "Selections, option selection limits and contest selection limits" has both R (option selection limit) and L (contest selection limit).

"To allow other voting methods, ElectionGuard allows a selection to be the assignment of a value in a range {0, 1, . . . , R},
where R is the option selection limit..."

Spec 2.0.0 Section 3.3.3 . p 26:

"In most elections, most contests have a selection limit of one. However, a larger selection limit
(e.g., select up to three) is not uncommon in some elections. Approval voting can be achieved by
setting the selection limit to the total number of options in a contest.

This gives us one_of_m, n_of_m and approval.

p 27:

"Cardinal voting methods. A range proof, i.e. a proof that a ciphertext is an encryption of one
of the values 0, 1, . . . , L is a generalization of the proof that a ciphertext is an encryption of zero
or one. It can be used to prove well-formedness of an individual selection when it is allowed for
options to receive multiple votes in a contest by a single voter. Using range proofs with a range
up to a certain option selection limit for the individual option as well as the contest selection sum
therefore enables cardinal voting methods such as cumulative voting, score voting, STAR-voting,
and Borda count in ElectionGuard."

Each of these cases needs more clarity and especially tests.

[JohnLCaron]

see #337