split poll ballot

[ostcar]

@bastianjoel This PR is mainly for OpenSlides/openslides-meta#543 But it has some other implications.

Basically, from an autoupdate perspective, I like the split between poll_ballot and poll_ballot_user. It is easier to hide the value of a ballot, but publish the information needed for the progress bar or for "have I voted".

On the rewrite, I realized, that the old system is not enough to see, if a user has already voted. The old system was to show a ballot (now ballot_user), if the request-user is in poll_ballot/acting_meeting_user_id or poll_ballot/represented_meeting_user_id. But this is not enough for delegates. For example if meeting/users_forbid_delegator_to_vote is set the true, a user can vote for him self. In this case the delegated user has no way to know, if there is a vote for this user or if he can vote again.

So I changed this system. Now, only the field poll_ballot_user/represented_meeting_user_id is relevant. A user can see the poll_ballot_user, if he can vote for that user. I think this is, what we need for "have I voted".

I did not implement this to 100%. For example, I do not check for the setting users_enable_vote_delegations, or if the request user is present. Should I do this? There are more corner cases (like the user was removed from the entitled group after he voted).

I am also not sure, if this is really, what we want. Because if the client does not get a poll_ballot_user if could either mean, that he has not voted or it could mean, that he is not allowed to vote. The client would need to check the second part in the same way as the server to answer this. This seems error prone.

Another option would be, that the autoupdate-service (or the vote service) would implement another handler under a separate url for polls, a user can vote on. It would return all started poll_ids where the user can vote with the information, for which user_ids he has not voted yet:

{
  "1": [1,2,3],
  "5": [1,2,3]
}

(The request user can vote on poll 1 and 5 for the meeting_user or user ids 1, 2 and 3)

This would make the restrictor easier and faster.

What do you think?

Another change is, that I implemented this open PR, since it was easier for the moment: #1428