Add support for event specific password protection

[owi92]

This adds the necessary backend and frontend implementations to allow event specific authentication as done by the ETH.

For technical information, see commit messages. @LukasKalbertodt to test this, you can use this DB command:

update all_events
set credentials = row(
    'sha1:9D4E1E23BD5B727046A9E3B4B7DB57BD8D6EE684',
    'sha1:3CBCD90ADC4B192A87A625850B7F231CADDF0EB3'
)::credentials
where title = 'Beyond Elasticsearch: user-facing search engines';

Of course you can use any other event. This will give the event the password user pass and the password word.

Test here (credentials are "user" and "password")

Closes #1186

[LukasKalbertodt]

Thanks for tackling this huge feature! The PR was nice to review commit by commit. And while below I have written quite a few comments, I think the general direction is absolutely correct, and all remarks are just "local problems", not really anything that requires rethinking everything.

Apart from the inline comments, while testing it I noticed these things:

• The "in flight" circle still spins when invalid credentials are entered on video page. Once the error is shown, the spinner should disappear. This only happens when entering them incorrectly twice... what.
• The whole page flashes when submitting credentials. Also, if the credentials were wrong, this means the entered credentials disappear, which is annoying if u only need to correct a typo.

I have to re-test everything again, but I think this is already a long enough review. I can test again after these things are fixed.

[LukasKalbertodt]

Mhhh this is tricky. So the thing you describe isn't great, right? Because yes, if we mix them together, we have no idea what was originally set. Just so I understand correctly: the only (as in 'singular', not to diminish the importance) reason to mix them together is to have easier queries, right? So we don't have to check both columns everywhere? Or is there more to it?

My gut feeling is to keep them separate. We might have already talked about this, in which case I forgot and would be happy to be reminded :D

Maybe in the future, the ACL selector allows users to select preview, read or write. Well mh no, that could work with either model. I suppose there is no operation that allows users to "just remove a single action permission" from an event, which is what would trigger the thing you mentioned here. The harvest process would also overwrite the whole ACL and wouldn't cause a problem with either model.

So right now I cannot think of a case where your model would break... mhhh. I might think about it a bit more.

[owi92]

is there more to it?

no, I don't think there is.

We might have already talked about this

You suggested doing it like this when we first planned the whole thing. I then said "no lets not, because reasons™". But when implementing it, I realized that I actually find it nicer to have only one filter/check for access things, taking the cue from how read and write roles are handled (whenever something requiring read access is checked, it's not necessary to also check for write, as read also includes all write roles).

[LukasKalbertodt]

Just did a pass over your latest changes and resolved my previous comments. I still haven't done the "difficult" things I said I will still do.

[github-actions]

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.