we need to store the keyid to be able to update the signature later in
case the missing key is added later.

as we write the cache in the gpg commit class already the read should
also happen there.

This also removes all logic from the main commit class, which just
proxies the call to the Gpg::Commit now.

we store the result of the gpg commit verification in the db because the
gpg verification is an expensive operation.

Previously, we used Psych, which would:

1. Check if a string was encoded as binary, and not ASCII-compatible.
2. Add the !binary tag in that case.
3. Convert to base64.

We need to do the same thing, using a new column in place of the tag.

The `members` table can have entries where `user_id: nil`, because people can
invite group members by email. We never want to include those as members,
because it might cause confusion with the anonymous (logged out) user.

Marking an issue as a duplicate will now also add an upvote on behalf of the author on the original issue.

I realized where the N+1 queries were actually coming from
project.protected_branches, but how come we cannot preload this,
or cache this at all?

Then I found that this is somehow a Rails limitation. What we're
doing before, eventually come to:

    project.protected_branches.matching

But why it's not cached? (project.protected_branches.loaded? is always
false) It's because matching is a class method, which is called on
the proxy. In this case, Rails cannot cache the result. I don't know
if this is possible to implement or not, because clearly this would
require some tricks to implement class methods on associations.

So instead, we could just pass project.protected_branches to
ProtectedRef.matching, then it would work regularly.

With this change, there's no more N+1 queries.