GitLab

The order is stdlib before external crates before internal modules.

Projects gained fields for visibility of individual features.

They also gained fields for devops and build configuration.
Leave out bindings for these for now.

The live Gitlab project from which we fetch sample data has been
updated.  Update our sample and expected results accordingly.

In order to generate data for commit e0312dcf (types: Add resource label
events, 2019-07-16, v0.1200.1~1^2~1) a label was added to our sample
issue.  Fetch updated data for the issue and revise expected values.

Andrew Chin authored Jul 23, 2019 and Brad King committed Jul 24, 2019

This will expose the merge issue id or the issue id of the MR/issue on
which the resource label event was created.

Andrew Chin authored Jul 16, 2019 and Brad King committed Jul 24, 2019

Resource label events record are events that are recorded whenever a
label is added or removed to an issue/merge request.

This Gitlab API was added in 11.1, and so any labels added/removed
before this release will not appear in the data returned by this API.

Projects gained a field indicating whether they have an empty repo.
Issues gained a field indicating whether there is an empty task list.

Issues and MRs also gained a field for task completion, but we leave
that unimplemented for now.

The merge requests field for multiple assignees now includes an entry
for a single assignee.  Namespaces of projects gained fields for a URL
and an avatar.

Users gained a "highest_role" field when queried as an admin.

Projects and Merge Requests also gained some fields.  Add samples
to our test data but leave out the implementation for now.

Also moved the map_err call to the end, which I think makes the function
a little easier to read

This field will be set when you request a single merge request:

    /api/v4/projects/123/merge_requests/456

But it's missing if you request a list of merge requests:

    /api/v4/projects/123/merge_requests

Tested against a gitlab 11.9.7 server

Issues gained a field for the number of merge requests referencing them.
Merge requests gained a field for the current user's access.

Merge requests gained fields to report a merge error and whether a
rebase is in progress.

Users gained a field for their public email address, if any.

Project hooks gained a `push_events_branch_filter` field.
Repository branches gained a `default` field.

* User information gained an optional `private_profile` boolean
  indicating whether the user has a private profile.  Additionally
  the `created_at` field is now optional as it is not exposed
  when the profile is private and the calling user cannot read it.

* PipelineBasic information gained a `web_url` field.

Ben Morgan authored Aug 15, 2018 and Brad King committed Aug 20, 2018

The `avatar_url` key for users and projects may be null if GitLab uses
its internal or default settings.  Change struct members for
`avatar_url` to `Option<>` to represent this possibility.

* RepoBranch now has a `can_push` field indicating whether the API
  user can push to the branch.

Projects with no readme have no such url.

* The `Master` access level has been renamed to `Maintainer`.

* A `cannot_be_merged_recheck` merge status was added.

* Merge requests gained `squash` and `allow_collaboration` booleans.
  The latter supersedes `allow_maintainer_to_push` which is now deprecated.

* Projects gained a `readme_url`.

Notes gained fields describing their resolution.
Merge requests gained a field describing its diff.

Issues gained a field for who closed them.  Projects gained a field
for their merge method.

Merge requests gained fields for users that merged or closed them
and for whether or not a maintainer can push.

Project hooks gained fields for confidential events.

The repository commit details now include the project id.

The `stats` associated with commit details is now optional because
the API endpoint gained an option to skip it.  See gitlab-ce commit
v10.4.0-rc3~1^2~5, which backports commit v10.5.0.pre~208^2.

Also update our gitlab API client to request the `stats` explicitly.
Later we could expose this option.

This is normally an integer, but if the count exceeds a certain number
of files, it comes back with "100+" or the like which is not an integer.