commit b8a3e7a3dad6c4e599f3720cd2adc75b723ffd93
author Dave Borowitz <dborowitz@google.com> Thu Feb 14 14:02:22 2019 -0800
committer Dave Borowitz <dborowitz@google.com> Mon Feb 25 15:55:34 2019 -0800
tree c76cd07adf755874d412c3bbb9f104d5b1896f77
parent 3860c21a9d8baf8120ac82b6ddb0356d59f67dd5

Allow setting blocking conditions on checkers

There are several use cases for providing slightly different behavior in
terms of blocking submission of a change when a checker fails. The most
obvious case is the one implemented in this change: a checker may be
configured to block submission when its check has not yet passed. With a
little imagination we can come up with more cases, such as ignoring
crashed checkers. So we don't want this to be a simple "required" bit.
On the other hand, taken to the extreme, we could support some kind of
arbitrary user-provided code to determine submittability. Our experience
with Prolog submit rules tells us that we do not want anything that
complicated[1].

Go one small step beyond a "required" bit and support a set of
conditions which are defined in a new BlockingCondition enum. This
allows for modest future extension within a simple interface.

[1] Plus, anybody who *really* cares could in theory write a submit rule
    plugin that inspects the checker results and does any computation
    they want.

Change-Id: I9fc198c5fceba0c5fc3df0760c614a81f58ac094