Passthrough traffic mirroring

[Razz4780]

Oh well

[t4lz]

One general thing: does passthrough_mirroring make sense as a user facing name?
Where does this name come from? Is that a well known term for what we're doing here?
If not, we should try to name it in a way that helps users understand what it does, especially what effect it has on them (which I am still not sure about). Like reset_mirrored_connections or iptables_mirroring (though this one is also a bit TMI).

[t4lz]

Can you help me understand why we need/want dynamic dispatch and can't/don't want to use normal generics, with a trait bounded type variable?

[Razz4780]

I would have needed to change the way ClientConnectionHandler is created, and it was a bit messy :V
Are you against dynamic dispatch? We can do an enum as well

[t4lz]

"invalid HTTP filter" looks pretty arbitrary in here. Even if it's the only possible reason for an error (is it?) wouldn't it be better to determine that with a match?

[Razz4780]

The error type of handle_client_message is fancy_regex::Error. Not sure what you mean by match. Do you want sth like this?

                    if let Err(error) = tcp_stealer_api.handle_client_message(message).await {
                        let error: fancy_regex::Error = error;
                        self.respond(DaemonMessage::Close(format!(
                            "invalid HTTP filter: {error}"
                        )))
                        .await?;
                    }

This would work as a reminder to update the error message, when someone changes the error type.
Or should the method return just Result<_, String> (message for DaemonMessage::Close) 🤔

[Razz4780]

One general thing: does passthrough_mirroring make sense as a user facing name? Where does this name come from? Is that a well known term for what we're doing here? If not, we should try to name it in a way that helps users understand what it does, especially what effect it has on them (which I am still not sure about). Like reset_mirrored_connections or iptables_mirroring (though this one is also a bit TMI).

I didn't think about it much tbh. I believe I came up with this name when presenting the idea internally. I agree that iptables_mirroring makes more sense. I wouldn't worry about it being too specific, as this config option is temporary. Eventually we'll drop packet sniffing and make iptables the only implementation.

[Razz4780]

Ok, there's something wrong here, some kind of a race.
I'm splitting this PR further, cause it's too big to find it ;_;