Evaluate possible improvements to BLOCK case handling for spam verdicts.

The following discussion from !52385 (merged) should be addressed:

• @cablett started a discussion:

  WDYT about creating an issue for whatever further iterations are planned for this? Otherwise this comment isn't very helpful since everything is already a draft 🙂

---

Initially, when work started on improving GitLab's spam-handling capabilities, only ALLOW, DISALLOW and CONDITIONAL_ALLOW were handled by spam_action_service.rb. However, with the introduction of https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/spam/spamcheck and active usage within the product !52385 (merged), there's now a need to process all verdicts. Thus, the BLOCK case was added. At the moment, BLOCK behaves exactly as DISALLOW, however, going forward and as Spamcheck matures, we should add functionality that actually enacts a user block, upon doing so admins can get a notification, etc. This opens the door for more automations that reduce engineering time spent enacting BLOCK verdicts.

when BLOCK_USER
          # TODO: improve BLOCK_USER handling, non-existent until now
          target.spam! unless target.allow_possible_spam?
          create_spam_log(api)