[APPSEC-9341] Enable configuring blocking response via Remote Configuration

[GustavoCaso]

What does this PR do?

Update ASM to be able to configure the blocking response via Remote Configuration.

Motivation:

Allow customers to change the blocking response via the DD UI

The PR includes multiple changes:

• Update the ASM remote capabilities
• Store in memory the actions configured via the DD UI. AppSec::Processor::Actions apart from storing in memory, we need to merge existing actions with the ones coming from the Remote Configuration and merging.
  The logic for merging replaces existing actions with new ones coming from remote configuration and keeps the ones not updated.
• Modify the AppSec::Response.negotiate method to account for the WAF result actions and the configured information

Additional Notes:

I've removed unused returned values from the methods Reactive::<Class>.subscribe, and Reactive::<Class>.publish

The returned values from the reactive engine are plain arrays ex: [:block, event] or [:monitor, event] those could be refactored into their own classes AppSec::Processor::Actions::Block and AppSec::Processor::Actions::Monitor. I left that exercise to a future PR.

How to test the change?

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

[codecov-commenter]

Codecov Report

Merging #3099 (d498af6) into master (24c162b) will increase coverage by 0.00%.
The diff coverage is 98.80%.

@@           Coverage Diff            @@
##           master    #3099    +/-   ##
========================================
  Coverage   98.16%   98.16%            
========================================
  Files        1323     1325     +2     
  Lines       75237    75457   +220     
  Branches     3430     3455    +25     
========================================
+ Hits        73855    74072   +217     
- Misses       1382     1385     +3     

Files Changed	Coverage Δ
lib/datadog/appsec.rb	90.32% <50.00%> (ø)
...dog/appsec/contrib/rack/request_body_middleware.rb	95.00% <66.66%> (-5.00%)	⬇️
lib/datadog/appsec/response.rb	97.14% <93.75%> (-2.86%)	⬇️
lib/datadog/appsec/component.rb	100.00% <100.00%> (ø)
lib/datadog/appsec/contrib/rack/gateway/watcher.rb	95.55% <100.00%> (ø)
...ib/datadog/appsec/contrib/rack/reactive/request.rb	100.00% <100.00%> (ø)
...tadog/appsec/contrib/rack/reactive/request_body.rb	100.00% <100.00%> (ø)
...b/datadog/appsec/contrib/rack/reactive/response.rb	100.00% <100.00%> (ø)
.../datadog/appsec/contrib/rack/request_middleware.rb	95.65% <100.00%> (+0.09%)	⬆️
...ib/datadog/appsec/contrib/rails/gateway/watcher.rb	97.14% <100.00%> (ø)
... and 19 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[lloeki]

LGTM, just a Q.

I think for those catch/throw protocols we should (but not in this PR) move to instances instead of hashes and arrays, it should make things easier to follow (and properly type-checked)

[lloeki]

Curious about the double array here: was it missing before or is that an intended API change?

[GustavoCaso]

In was missing 😨

[GustavoCaso]

While missing the functionality still worked because we did not use the values

[:block, {}].any? {|action, _event| action == :block }
# => true

We now care about the returned value with the code changes on the request middleware. We use find rather than any?

blocked_event = request_response.find { |action, _options| action == :block }

Old code

blocked_event = [:block, {}].find {|action, _event| action == :block }
#=> :block

New Code

blocked_event = [[:block, {}]].find {|action, _event| action == :block }
# => [:block, {}]

[GustavoCaso]

I think for those catch/throw protocols we should (but not in this PR) move to instances instead of hashes and arrays, it should make things easier to follow (and properly type-checked)

Absolutely 😄

I mentioned in the PR description

The returned values from the reactive engine are plain arrays ex: [:block, event] or [:monitor, event] those could be refactored into their own classes AppSec::Processor::Actions::Block and AppSec::Processor::Actions::Monitor. I left that exercise to a future PR.