This MR alters the semantics of the mergeability check so the list API
does not enqueue rechecks by default. The previous behaviour can be
restored by use of a REST projection (`with_merge_status_recheck`).

Since the structure of the response remains the same, and even the
content of the returned response, this is not, strictly speaking, a
backwards-incompatible change. However, users who rely on this in the
list API will find they get stale data; rather than going to the single
MR endpoint, the projection gives them a way to specify that they need
the previous behaviour.

Longer-term, we should look at refreshing merge status independently of
any frontend actions. Since we can deduplicate sidekiq jobs now, the
best way to do that is probably to just enqueue a mergeability check
for every affected MR on push, and place strict limits on that sidekiq
queue's concurrency characteristics.