fail gracefully for pointless merge

From https://code.launchpad.net/~mrazik/jenkins-launchpad-plugin/stale-locks-take2/+merge/166452 :

>> There is one issue, though -- fasttrack merges. I just noticed a pointless
>> merge and as far as I can see it is because the autolanding was triggered
>> while the other generic-land (which I started manually due to some unrelated
>> bug) was still running.
>> OTOH the problem is probably not introduced by this branch and explains why
>> I'm seeing these pointless merges every now and then.
>
> I was wrong about this. It is a newly introduced regression. OTOH solving this
> would most likely add yet another level of complexity and:
> 1. even if it happens nothing really bad happens (just the pointless merge
> error)
> 2. it shouldn't be happening very often as the generic-land is usually
> finished in 15 mins (the time between to triggering operations)

Right. The fasttrack MPs never call the autolanding job, they go straight to generic-land. As this new method looks for the MPs that were started from the autolanding job, it won't find a downstream build due to the upstream check.

I agree that we are safe for now as long as the second generic-land does not change the state of the MP from Merged to something else.

I think there are two options how to fix this:

1. Catch the exception and make the autoland.py command to exit with 1 (i.e. the generic-land job will fail and will indicate a problem).

The issue from https://code.launchpad.net/~mrazik/jenkins-launchpad-plugin/stale-locks-take2/+merge/166452 will be therefore generating a bit of noise (but not too much as this should really happen very rarely).

Merge proposals that are still Approved but should be Merged (i.e. launchpad didn't detect the merge correctly) will stay Approved with no additional information. OTOH the generic-land job will fail (so indicating there is a failure) as well as the "check for stalled MPs" job. This will need a manual interaction and changing the job state to "Merged".

2. Catch the exception and make a comment in the merge proposal. For example:
"Merging reported a Pointless merge. This branch is most likely merged already. Please check if it is indeed the case and change the state to Merged manually."

The issue from stale-locks-take2 branch would then generate a bit of noise directly on the merge proposal (possibly confusing devs).

In the 2nd case (merged branch which was not detected as merged) it will give a bit more hint to the developers and people who are not watching the "check for stalled MPs" job will be able to correct the issue.