Adds Gitlab provider

[dinosk]

Implements #8

This PR adds a Gitlab provider using the https://github.com/xanzy/go-gitlab client.
The mapping between gitprovider and Gitlab entities:

Repo - Project
Org - Group
Team - Group

Specifics for this provider:

• Projects can be created in user or group namespaces.
• Projects can be shared with groups or subgroups, in the subgroup case, the full name of the subgroup is required group/subgroup.
• For Projects that have empty repositories and no default branch set, the default branch is set to master.
• Support for conditional requests is added for the gitlab instances that support the feature.

[codecov-commenter]

Codecov Report

Merging #51 into master will increase coverage by 2.77%.
The diff coverage is 62.14%.

@@            Coverage Diff             @@
##           master      #51      +/-   ##
==========================================
+ Coverage   56.07%   58.85%   +2.77%     
==========================================
  Files          24       38      +14     
  Lines         913     1694     +781     
==========================================
+ Hits          512      997     +485     
- Misses        361      571     +210     
- Partials       40      126      +86     

Impacted Files	Coverage Δ
gitprovider/errors.go	0.00% <ø> (ø)
gitlab/client_repository_deploykey.go	41.02% <41.02%> (ø)
gitlab/client_repository_teamaccess.go	45.61% <45.61%> (ø)
gitlab/resource_teamaccess.go	50.00% <50.00%> (ø)
gitlab/client_repositories_user.go	55.88% <55.88%> (ø)
gitlab/util.go	56.84% <56.84%> (ø)
gitlab/auth.go	62.82% <62.82%> (ø)
gitlab/client_organization_teams.go	64.00% <64.00%> (ø)
gitlab/gitlabclient.go	64.05% <64.05%> (ø)
gitlab/resource_deploykey.go	66.10% <66.10%> (ø)
... and 20 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3134269...d139d6e. Read the comment docs.

[foot]

I might have added this comment here:

Include scheme if custom

But I don't think this should be the case. We shouldn't need to user to include the scheme when declaring custom domain vs. no-domain if using gitlab.com. wdyt?

[dinosk]

This was the original attempt, but it was added because of go-gitlab returning the error below when the custom domain was passed.

Unexpected error:
      <*url.Error | 0xc0002aa4b0>: {
          Op: "Get",
          URL: "gitlab.dev.wkp.weave.works/api/v4/projects/dinos%2Ftestrepo",
          Err: {
              what: "unsupported protocol scheme",
              str: "",
          },
      }
      Get gitlab.dev.wkp.weave.works/api/v4/projects/dinos%2Ftestrepo: unsupported protocol scheme ""
  occurred

[foot]

Good point. I guess it comes down to if we wanna support http? Which as it hosted internally sometimes is "yes". But it would be nice to support scheme-less urls for "tidyness".

c, err = NewClient(gitlabToken, "", WithDomain("gitlab.works")) // "https://gitlab.works"
c, err = NewClient(gitlabToken, "", WithDomain("https://gitlab.works")) // "https://gitlab.works"
c, err = NewClient(gitlabToken, "", WithDomain("http://gitlab.works")) // "http://gitlab.works"

Could be a follow up issue.

[dinosk]

I agree, it could default to https and mention it in the error message, only thinking if it's predictable. Will open an issue 👍

[foot]

💯 !

[hiddeco]

Looks OK to me, but please note I am by no means an expert on this project.