Remove `unless target.allow_possible_spam?` once this flag has been passed to `SpamVerdictService`

  1. Simplifies and encapsulates the checking of target.allow_possible_spam? to a single place in SpamVerdictService, instead of in multiple places in the case statement of SpamActionService
  2. Introduces a new verdict constant OVERRIDE_VIA_ALLOW_POSSIBLE_SPAM to make this logic path explicit, and facilitate further simplification of the case statement in SpamActionService
  3. Other changes:
    • Makes order of spam Verdict constants consistent
    • Redesigns existing feature spec for spam/CAPTCHA

Note that the original description of this issue called for the value to be passed as an explicit argument to the SpamVerdictService constructor. However, since that time, we have added additional logic to SpamVerdictService which relies on the passing along the entire target object to the SpamCheck client, and there is also other coupling to read properties off target. Therefore, it seems acceptable to let SpamVerdictService directly access this flag. We should probably revisit and clean up the coupling/cohesion of access to target properties across SpamActionService and SpamVerdictService, and we've got a task item about that here, but that can be done in a future refactor.

ORIGINAL DESCRIPTION: Currently the SpamVerdictService can access these things itself, but I'd like to move towards an argument based model where these are provided as parameters rather than asking the objects directly.

Edited by Chad Woolley