GitLab

Fixes #17.

The goal is to avoid upvotes/approval to extend the "no review"
deadline. This happened when a developer was approving/upvoting a MR:
- between 0h to 24h before the "no review" deadline (the MR switches from
  "Reviewable" to "Acceptable" and wait 24h after the vote).
- after the "no review" deadline (the MR switches from "Accepted" to
  "Acceptable" and wait for 24h to go back to its previous state).

Ignoring the presence of votes if there are only upvotes/approvals for
the "no review" transition should solve both issues without any
consequence on the other part of the process:
- if the upvote occurs between 0-48h after the creation of the MR, then
  the "no review" transition will fail during the 0-72h period (deadline
  not reached). During this period, the MR will considered Acceptable,
  then Accepted 24h after the first upvote. After 72h, the "no review"
  transition will succeed no matter what.
- if the upvote occurs between 48-72h, the "no review" transition will
  fail, MR will be switched to Acceptable. But after 72h, the "no
  review" transition will succeed no matter what, switching MR to
  Accepted.
- if the upvote occurs after the "no review" deadline, the "no review"
  transition will succeed no matter what, so the MR will be kept as
  Accepted.

Note: all these statements suppose there is no (resolvable/resolved)
discussion thread opened and/or closed on the MR at all. If this is the
case, the "no review" transition will fail in any situation, and the
process will fallback to the previous workflow behavior.

Fixes #16.

The new "Inactivity" deadline for Developer+ MRs now takes into account
both the first version of the MR and the last version of it.

With the default threshold values, the goal is to put developer unreviewed MRs
in Accepted state after the later of 24h after the last non simple change
(ie fast-forward rebase) and 72h after the MR creation time (or
out-of-draft time).

Fixes #15

MR that are "stuck" in InReview status for a certain amount of time
without any user activity (60 days by default) will be considered as
"Staled", and put in the according state.

DevScore is supposed to return the last time the score changed its sign.
With approval method, score sign cannot change more than once:
- either the score is zero (no vote)
- or the score is strictly positive since the first approval
So the time returned by the function must be the time of the first
approval (and not the last).

MR Developer score can now be computed through two different methods:
- the old one based on the thumbsup/thumbsdown emojis
- a new one based on the Developers approvals

The bot tries to determine which method should be used to compute the
vote: if only one method provides a valid score (with a correct update
time), it is selected. In any other case, the `preferred-score-method`
parameter is used.

Fixes #10

System notes (notes with flag "system=true") seem to be the only way to
get the "all resolve thread" event.

Fixes #9

Add the ability to select specific MRs to be processed.
This is mainly for debug purpose.

By comparing MR version diffs, it should detect simple rebases.
Ignore these versions to get a more accurate value of the MR version
creation date.

This is not relevant for now

do not publish the detailed reasons in published report

The email notifications will be a bit fancier

Only output checks that ended to an actual state transition.

never forget to reset the intermediate list...

sometimes gitlab API does not send stable information about MRs, like
mergeability.
Add a Quantum state to the graphs that forces homer to do nothing as
long as it cannot get stable info.