agent: add tcp connection disruptor

[nadiamoe]

Description

This PR implements the TCP connection disruptor as proposed in #154.

In its current state, includes a working disruptor with its associated command, which has been tested manually.

The following things remain to be addressed:

• The current NFQueue library sometimes hangs when closing, for which a workaround has been added Replaced.
• Unit test for the new iptables helper
• Integration tests for the command using testcontainers
• Kill connections in both directions, instead of only for ingress packets
• Rebase the ungodly amount of commits

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make test) and all tests pass.
• I have run relevant integration test locally (make integration-xxx for affected packages)
• I have run relevant e2e test locally (make e2e-xxx for disruptors, or cluster related changes)
• Any dependent changes have been merged and published in downstream modules
  

[pablochacin]

@roobre I'm liking the PR. I have some comments in the structure of the code but I think overall we have a very solid base. I haven't had time to run the tests, I'll do it later but I wanted to give you some feedback as soon as possible.

Also, I remember you commented you were concerned regarding the performance. I think there are two relatively easy changes we could try, if not in this PR, in a follow-up PR but I want to take note here so we don't forget:

1. Copy only the metadata of the packages, instead of the whole package. I haven't checked how this would actually work, but I think it is worth researching
2. Change the way we calculate the hash for each connection. This is in the critical path for processing packages We are using CRC32. After some research, I found xxHash which is optimized for small inputs, as in our case. Moreover, given our input is of a fixed size, I was wondering if we could use a block cipher instead.

[pablochacin]

Only to minor non blocking comments