Use auto merge unless ready to be enqueued in the merge queue

[Urgau]

As discussed in #2449 (comment), let's use the auto merge functionality when the PR is not yet ready to be enqueued in the merge queue (PR CI still running, ...).

That way PRs that are not yet ready can still be @rustbot merge-ed.

I tested the logic in my fork and it seems to work as expected.

Details

cc @samueltardieu

[Kobzol]

The mergeable statuses always confuse me :) Not sure if HasHooks is also something that would work for directly enqueuing? We'll see in practice, I guess.

I wonder what happens if you enable auto-merge when the PR is already mergeable? Does it also work? I'd hope it would.. :)

View changes since this review

[Urgau]

I wonder what happens if you enable auto-merge when the PR is already mergeable?

Depends on what you mean by mergeable, if you mean no conflicts, it works, but if you mean CI is green, then no, it gets rejected by GitHub as being already ready (the "clean" state"), and as such we need to enqueue it in the merge queue instead.

[Kobzol]

If we could reliably detect that, then we could always try to auto merge, and if that fails, then enqueue. But the current solution of this PR should also work, so fine by me.

[Urgau]

That was my first instinct as well, but GitHub doesn't give us nice error code, only an error message: "Pull request Pull request is in clean status" (yes, there really is a double "Pull request" at the start of the message, not a typo from me).

If you're fine doing some error message matching, we can switch to auto-merge first and if rejected for "clean" then enqueue.

[Urgau]

Let's go with the mergeable_state check (feels cleaner to me).