Support more code review services

[jerry-skydio]

With a little bit of refactor we could support other services such as gitlab, etc. This would probably require ownership by a motivated contributor.

[Geethree]

I now use Gitlab. Can you drop me some bread crumbs @jerry-skydio ? Happy to take a stab at it.

[jerry-skydio]

awesome! here are my thoughts but you might learn more as you go

• we first need a bit of refactor to move things that are github specific vs things that are generic "code review" related. These include but aren't limited to
• PrComment, PrInfo, PrUpdate in github_utils.py
• get_github_repo_info() in git.py
• github_connection() in revup.py
  I think we can move the generic things into a new file called "code_review_interface.py" (naming can vary). This can provide the generic structures related to all code review providers, as well as a CodeReviewInterface class, with the functions in github_utils.py turning into its classmethods (query_everything, create_pull_requests, update_pull_requests). We can move the functionality from github_utils into a new file with a class that inherits CodeReviewInterface. I would probably also take this chance to move all github sources into a github/ subdir so we can reduce toplevel clutter.

after that all that remains is to implement the same interface in terms of gitlab. a few notes there:

• we'll want to detect github vs gitlab in the remote URL parsing which happens pretty early on
• auth is probably the next thing to think about. with github we're moving away from storing a plaintext token in ~/.revupconfig (insecure! and not really best practice considering people tend to put their dotfiles on github) to using git credentials-helper. the nice thing is that gh also uses that in the backend, so we're able to share credentials with it automatically. it would be nice if gitlab had an easy way to do this so we can start out the right way
• I'm not that familiar with gitlab so i'm not sure if all the same concepts apply (reviewers, assignees, labels, comments, draft, etc). you might also discover new concepts you want to support.
• It looks like gitlab supports graphql as well so I'd recommend using that and doing the same strategy as we do with github where we batch as many operations into a single graphql request as possible. This is really important for keeping network roundtrip times low.

[jerry-skydio]

also see #172 which could be a relevant way to auth for gitlab as well