This causes a regression in gvproxy when it's used by podman:
containers/podman#23616

Reverting inetaf/tcpproxy commit 2862066 is a bit convoluted, as we need
to first undo the module name change (inet.af/tcpproxy ->
github.com/inetaf/tcpproxy) done in commit 600910c
and then a go module `replace` directive to redirect the no-longer
existing inet.af/tcpproxy to the commit we want in github.com/inetaf/tcpproxy/

This way, the module name in gvisor-tap-vsock go.mod and in
github.com/inetaf/tcpproxy go.mod are the same (inet.af/tcpproxy), and
we can use older commits in this repository.

It's unclear what's causing the regression, as the commit log/PR
description/associated issue don't provide useful details:
inetaf/tcpproxy@2862066

The best I could find is:
tailscale/tailscale#10070
> The close in the handler sometimes occurs before the buffered data is
forwarded. The proxy could be improved to perform a half-close dance,
such that it will only mutually close once both halves are closed or
both halves error.

and inetaf/tcpproxy#21 which seems to be the
same issue as inetaf/tcpproxy#38 which is the
issue fixed by the commit triggering the regression.

What could be happening is that before inetaf/tcpproxy commit 2862066,
as soon as one side of the connection was closed, the other half was
also closed, while after commit 2862066, the tcpproxy code waits for
both halves of the connection to be closed. So maybe we are missing a
connection close somewhere in gvproxy's code :-/

This causes a regression in gvproxy when it's used by podman:
containers/podman#23616

Thanks to Maciej Szlosarczyk <maciej@sosek.net> for investigating and
finding the faulty commit!

Reverting inetaf/tcpproxy commit 2862066 is a bit convoluted, as we need
to first undo the module name change (inet.af/tcpproxy ->
github.com/inetaf/tcpproxy) done in commit 600910c
and then a go module `replace` directive to redirect the no-longer
existing inet.af/tcpproxy to the commit we want in github.com/inetaf/tcpproxy/

This way, the module name in gvisor-tap-vsock go.mod and in
github.com/inetaf/tcpproxy go.mod are the same (inet.af/tcpproxy), and
we can use older commits in this repository.

It's unclear what's causing the regression, as the commit log/PR
description/associated issue don't provide useful details:
inetaf/tcpproxy@2862066

The best I could find is:
tailscale/tailscale#10070
> The close in the handler sometimes occurs before the buffered data is
forwarded. The proxy could be improved to perform a half-close dance,
such that it will only mutually close once both halves are closed or
both halves error.

and inetaf/tcpproxy#21 which seems to be the
same issue as inetaf/tcpproxy#38 which is the
issue fixed by the commit triggering the regression.

What could be happening is that before inetaf/tcpproxy commit 2862066,
as soon as one side of the connection was closed, the other half was
also closed, while after commit 2862066, the tcpproxy code waits for
both halves of the connection to be closed. So maybe we are missing a
connection close somewhere in gvproxy's code :-/

Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>

This causes a regression in gvproxy when it's used by podman:
containers/podman#23616

Thanks to Maciej Szlosarczyk <maciej@sosek.net> for investigating and
finding the faulty commit!

Reverting inetaf/tcpproxy commit 2862066 is a bit convoluted, as we need
to first undo the module name change (inet.af/tcpproxy ->
github.com/inetaf/tcpproxy) done in commit 600910c
and then a go module `replace` directive to redirect the no-longer
existing inet.af/tcpproxy to the commit we want in github.com/inetaf/tcpproxy/

This way, the module name in gvisor-tap-vsock go.mod and in
github.com/inetaf/tcpproxy go.mod are the same (inet.af/tcpproxy), and
we can use older commits in this repository.

It's unclear what's causing the regression, as the commit log/PR
description/associated issue don't provide useful details:
inetaf/tcpproxy@2862066

The best I could find is:
tailscale/tailscale#10070
> The close in the handler sometimes occurs before the buffered data is
forwarded. The proxy could be improved to perform a half-close dance,
such that it will only mutually close once both halves are closed or
both halves error.

and inetaf/tcpproxy#21 which seems to be the
same issue as inetaf/tcpproxy#38 which is the
issue fixed by the commit triggering the regression.

What could be happening is that before inetaf/tcpproxy commit 2862066,
as soon as one side of the connection was closed, the other half was
also closed, while after commit 2862066, the tcpproxy code waits for
both halves of the connection to be closed. So maybe we are missing a
connection close somewhere in gvproxy's code :-/

Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Tested-by: Maciej Szlosarczyk <maciej@sosek.net>