feat: improve handling redistribution of votes

[RonaldTreur]

The approach as to how excess votes are redistributed after a winner was selected, or a candidate was eliminated seems too simplistic and honestly just wrong to me.

I added the following two tests:

it('should correctly handle a scenario where a winner has no backup candidates to assign excess votes to', () => {
    // Quota values over time: 90, 30, 16 2/3
    const voteRecords: VoteRecord[] = [
      { voteCount: 170, voteOrder: ['Alice'] },
      { voteCount: 10, voteOrder: ['Alice'] },
      { voteCount: 40, voteOrder: ['Bob'] },
      { voteCount: 25, voteOrder: ['Charlie'] },
      { voteCount: 10, voteOrder: ['Dave', 'Charlie'] },
      { voteCount: 10, voteOrder: ['Eve', 'Charlie'] },
      { voteCount: 5, voteOrder: ['Frank', 'Charlie'] },
    ];

    const { winners, tieCount } = calculateStvWinners(voteRecords, 2);
    expect(winners).toEqual(['Alice', 'Bob']); // Alice wins first, followed by Bob
    expect(tieCount).toBe(0);
  });

  it('should correctly handle a scenario where a winner has a backup candidate defined for only a small portion of excess votes', () => {
    // Quota values over time: 90, 33 1/3, 20
    const voteRecords: VoteRecord[] = [
      { voteCount: 170, voteOrder: ['Alice'] },
      { voteCount: 10, voteOrder: ['Alice', 'Eve'] },
      { voteCount: 40, voteOrder: ['Bob'] },
      { voteCount: 25, voteOrder: ['Charlie'] },
      { voteCount: 10, voteOrder: ['Dave', 'Charlie'] },
      { voteCount: 10, voteOrder: ['Eve', 'Charlie'] },
      { voteCount: 5, voteOrder: ['Frank', 'Charlie'] },
    ];

    const { winners, tieCount } = calculateStvWinners(voteRecords, 2);
    expect(winners).toEqual(['Alice', 'Bob']); // Alice wins first, followed by Bob
    expect(tieCount).toBe(0);
  });

The only difference between the two is that the second person to vote for Alice has selected a backup candidate (Eve).
Unexpectedly (with the current codebase), this resulted in the second test failing, as Eve was selected as the 2nd winner.

The reason for this is that the current code will assign all excess votes (90!) to Eve, as she was the only backup candidate provided. This is an extreme example, but the code responsible did influence the actual outcome of the first round of (the first) Council voting.

My suggestion would be to: Ignore PVP that does not have a backup-candidate provided. Instead, lower the quota accordingly.

To accomplish this, two changes are required:

• calculate the voteMultiplier by dividing the number of excess total votes by the original total votes. At present, the excess total votes are divided by the total number of backup votes, which means all excess votes are assigned as long as one person provides a backup option (and they are all assigned there).
• always lower the quota to account for lost votes (no backup option provided) instead of only doing this when no one provided a backup option.

The first change would result in Charlie winning in the second test/example above. Incorporating the second change will pass the win to Bob instead.

A case could be made to subtract only the unassigned excess votes from the quota calculation, in which case Charlie would win in the above test (due to both remaining below the updated quota (60) and Charlie ending up being the last man standing). This is likely a change for another PR.

[RonaldTreur]

Updated test as the output changed.

[RonaldTreur]

Updated the test so it would actually trigger an elimination (I assume it did originally, but not in the updated code).

[RonaldTreur]

Updated the test so it would actually trigger an elimination (I assume it did originally, but not in the updated code).

[RonaldTreur]

Had to update the next few tests as less input is passed to this method. This was also part of #3, but I had to do it here as there was just no need for the excess parameters anymore.

[RonaldTreur]

This should have been the case from the get-go, see also #3

It is necessary here though, as we want to ensure we use the updated voteMultiplier.

[Buzzec]

This will be on hold pending a PIP decision.