fix(rules): handle deletion async

[andrewazores]

Fixes #1093

• ignore cleanup failures, always respond 200
• do not include cleanup failures in response body
• handle deletion cleanup async
• use RecordingTargetHelper to clean up

This change makes Automated Rule deletion happen asynchronously, similar to how Automated Rule activation is also asynchronous.

Prior to this change, creating an enabled Rule definition was a fast request that simply defined the Rule and returned. Any
recordings created by that rule were processed asynchronously and separately from the original request. Deleting a rule, on
the other hand, was synchronous - all matching targets would be tested again for rule applicability, and recordings would be
stopped on any matching targets. When all of those tasks were completed the deletion response would finally be sent back to the
requesting client, with a 500 status code indicating that at least one of those tasks failed and a 200 if everything succeeded.

With this change the deletion acts the same way as creation/activation. The rule definition deletion is the only thing blocked on
before the API response is sent to the client. If clean up is required then this is handled asynchronously in the background.

(Worth noting: Rule creation also used to be a synchronous request but was made async some time ago, and deletion was never updated the same way)

[andrewazores]

CI keeps failing here, I think due to #1083 mostly. #1096 should clean it up and make the tests more reliable.

The AutoRulesIT is the first test to fail in these bad runs and because it fails it doesn't properly clean up after itself. I think the extra targets get left running, and it also leaves credentials and rules definitions behind, so most tests that run afterward also fail because there are more targets than expected or the automated rule has triggered more recordings than expected, etc.

[tthvo]

Looks good :D