Introduce canceling on delete flag and start

to move some logic to be sync. Do not enable
the feature flag without completing TODO.

In most cases projects do not have any requirements, so we can avoid
scheduling processing of any requirements which can be present in
build's artifacts.

Changelog: performance
EE: true

Once we deploy this new worker, security scan entries and findings will
be saved by the new worker class.
We will stop using the old worker but we can't remove it completely as
there might be some jobs enqueued for the worker.

Process requirements reports in job artifacts and
set 'passed' status for existing open requirements.

- to incorporate already existing logic
  in recently refactored ci minutes
  area.

The plan for RSpec 4.0 is to disable monkey patching:
https://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero-monkey-patching-mode

This commit stops using RSpec monkey patching:
https://relishapp.com/rspec/rspec-core/docs/configuration/zero-monkey-patching-mode

- clearer for user when email received on what
  is being alerted upon.

This stores scans run by Secure Products

Notifications should be only sent for GL.com customers.

Mutliple levels of notifications are suppoerted.
We just send the notification when a new level has been reached.

An email is sent to all owners when all CI minutes have been used, this
also includes extra CI minutes.

ChatOps used to be in the Ultimate tier.

- Remove unwanted chat was failing as a consequence of moving external support from Premium to starter. We have a dependency on config_processor a project with a repository must be used

Closes #5171

- Remove unwanted chat was failing as a consequence of moving external support from Premium to starter. We have a dependency on config_processor a project with a repository must be used

Closes #5171

The chatops solution is built on top of CI pipelines and essentially
acts as a different UI for scheduling pipelines manually. Pipelines
scheduled via chat have access to an environment variable called
"CHAT_INPUT". This variable stores the arguments that were passed to the
chatops command.

Output is retrieved by reading specific trace sections from the build
output. There are two sections supported (in this order):

1. chat_reply
2. build_script

The "chat_reply" is a trace section that one has to generate themselves,
"build_script" in turn is provided by default. The "build_script" trace
section also includes the output of any commands executed in the
"before_script" list. If one doesn't want to display this output they
should generate the custom "chat_reply" trace section.

Responses are sent back via Sidekiq using the ChatNotificationWorker
class. This ensures that existing CI related jobs won't get slowed down
if Slack (or another chat service) is not responding.