hooks, etc.: Restructure concurrency and data flow

Previously we accepted handler connections at hooks_handle and used a
mess of channels and concurrent maps to let receive_pack handle the
session. This doesn't work well because there are conditions where a
push occurs but the hook is not called, e.g. when the destination branch
is up to date. There is no reliable way of checking whether the
subprocess is going to call the hook or not; it's technically possible
to parse stderr but that interface is not guaranteed to be stable and
IIRC has changed in the past). So receive_pack would be waiting on the
channel to receive a hooks connection to handle but it'll never receive
one, causing a deadlock. This entire thing was overengineered and was
very prone to error.

Here we let receive_pack put the cookie into the map, then start and
wait for the subprocess to finish. When the hook actually runs and
connects to its UNIX domain socket, the handler would check its cookie
within the map. If the hook doesn't run, then nothing happens. The
git-receive-pack subprocess blocks the execution of the SSH handler,
and when git-receive-pack exists, the SSH handler (using a defer)
deletes the cookie from the map.

There may be caveats in signal handling or other cases that cause the
cookie to be deleted from the map prematurely.

0 files changed, 0 insertions, 0 deletions