Add voting methods

[oliverbarnes]

(This emerged on liquidvotingio/decidim-module-liquidvoting#31 (comment))

Add a new voting_method graphql field to vote mutations and queries, and to voting results.

A string field mapping to entries in a new voting_methods db table (with matching Ecto schema) that gets upserted so we avoid the need for pre-seed or for an admin interface to manage it.

It would map to an association for Vote and VoteResult schemas. For Vote, for example:

defmodule LiquidVoting.Voting.Vote do    
  schema "votes" do
    belongs_to :voting_methods, VotingMethods

Same for VotingResult.

> (@jinjagit) And this field would be optional? To allow our api to still work in it's purest, no voting method specified, way, as (for example) in the api readme examples. So we could use a create_vote api function, for example, that picks up the voting_method field if present and does the voting_method table stuff, and if no voting_method is specified the votes/results etc. are processed as they are now (without considering any voting_method).

👍 agreed, it should be optional. To avoid splitting db queries we can just have an empty entry in the db.

[EDIT: voting_method now required, not optional - see comment below]

The new VotingMethod schema would also be constrained by organization id.

[jinjagit]

Just to help me think this through, table would just have 2 columns:

voting_method  |   org_uuid  
----------------------------------------------------------------------
supports       |   02809347501934785
endorsements   |   02809347501934785
               |   09708789079875676

Or do we need uuids for voting_method too?

[oliverbarnes]

We need uuids for VotingMethod too (for the associations, and Ecto might need it behind the scenes), and a composite index on organization_uuid and voting_method

[jinjagit]

voting_method will be required when creating a vote.

In discussion with Oliver, we decided this was the easiest way to avoid the complexities of trying to create a unique index against possible null values (do-able, but then creates Postgrex exception, which would need special handling, if an empty string is given for voting_method.name) & to also avoid explicitly setting a default string value. This means a voting_method is required even when a voting context (e.g. proposal_url) only has one 'method'.

voting_method will be associated with a result, and will be required when initiating a result calculation (not yet implemented).

voting_method may be required for list_votes, though I am currently undecided on this, as I can see pros and cons in having both a list_all_votes (of all voting methods) and a list_votes_for_voting method action.

[jinjagit]

Closing, as this was completed in #227