Come to better abstractions for fault injection

[pablochacin]

Presently, fault injection capabilitites are defined in a series of interfaces that defines a method for each type of fault.
For example, the ProtocolFaultInjector defines the methods for injecting HTTP and gRPC faults.

Each disruptor (PodDisruptor, ServiceDistruptor) has to implement these methods.

The implementation of each fault injection method for each disruptor is quite similar, differing mostly in the type of fault to be injected. To inject a fault the disruptor needs to translate this fault to a command to be sent to the agent in the target using an agent controller.

This situation creates a series of issues:

• Duplicity of logic in the fault injection between disruptors and between protocols. This causes inconsistencies such as the one reported in #299
• Complexity of tests: presently to validate how a fault is mapped to the corresponding agent commands it is necessary to instantiate the disruptors. This requires considerable setup and also creates the necessity to duplicate the tests for each disruptor
• No clear separation of concerns

All the above seems to point to the need to reconsider the abstractions used for fault injection. In particular to decouple the fault injection from the disruptor to allow reuse across disruptors.

One initial analysis points to the idea of separating the fault injection logic into a component that has the sole responsibility of mapping faults to commands for a given target, validating that this mapping is possible/allowed.