Cleanup redundant refs/keep-around

This was brought up by @DouweM in https://gitlab.com/gitlab-org/gitlab-ce/issues/36803#note_38287997

I wonder if we could somehow figure out which keep-around refs are redundant. If I (non-force) push into an MR's branch 3 times, I end up with 3 keep-around refs, but we really only need the latest, since the first 2 commits are ancestors of that commit and will automatically be kept around too.

Of course iterating over all keep-around refs and checking is_ancestor? (through merge_base) for each combination of them smells like O(n^2)...

And @smcgivern has a good point about backtracking in https://gitlab.com/gitlab-org/gitlab-ce/issues/36803#note_38289027

interesting point! I think that could definitely work if we could do it efficiently. It also worries me a little. Say we allow deleting a commit in future (by removing all hidden refs pointing to it, and the associated DB objects if necessary) as per https://gitlab.com/gitlab-org/gitlab-ce/issues/19376.

Assume that we have abc -> abd -> abe, and have refs pointing to each of these revisions.

Under this scheme, we'd've only kept around abe (because the others are redundant), but then if you delete abe, we'd need to somehow figure out that we need to create a ref pointing to abd again.

I don't think this is insurmountable, but we'd need to do that tracking somewhere (commits table + a references table? It's possible this would also make the redundant ref calculation faster).