Signed-off-by: Sven Strickroth <email@cs-ware.de>

ci: overwrite nonsense in /usr/local during macOS setup

GitHub Actions has borked their homebrew setup by first `brew
installing` things into `/usr/local` _and then_ putting their
own things in their place (eg `python`).

This breaks Homebrew, since it thinks it has `python` installed, but
it's actually something else.

Try to avoid using things that are in this bad state.

https://github.com/orgs/community/discussions/78266

remote: fix memory leak in git_remote_download()

Use #!/bin/bash for script with bash-specific commands

connect_opts is created with its custom_headers and proxy_opts->url possibly
allocated on heap, just like in git_remote_fetch(). But unlike in
_fetch(), it is not disposed at the end of the function, thus causing
memory leak.

remote: optionally report unchanged tips

Like in the previous commit and in git, we reject a path that looks like an
option to avoid injection into the command we ask the remote to execute.

If you pass along something like `-oProxyCommand=...` as the hostname, we would
pass that along to ssh unbeknownst to us and potentially also the user, if
they were asking a tool to recursively clone submodules.

This is the same fix as mainline git although they don't separate the username
and host for ssh so ours looks like it's checking more.

This function returns true if the string starts with a `-` as that could be used
to inject options into commands we execute.

We now have no "big single object" that contains thread state.

Now that thread-local error data is handled in error, move the thread
local data out of the `threadstate` object, since it has now become
useless indirection.

Instead of having a separate type for saving state, we can re-use the
`git_error` structure. In practice, saving the error code along with the
`git_error` information has not proven necessary or useful, so it can be
removed to simplify down to re-using a single structure.

Most callers only need to _get_ error messages. Only callers implemented
more complicated functions (like a custom ODB for example) need to set
them.

(Callback users should likely ferry their own error information in their
callback payload.)

Callers want to be able to simply call `git_error_last()->message`,
not have to worry about whether `git_error_last()` returns NULL or not.

The error handling in the ssh certificate callback is straightforward.
There's no error messages from an external library that need to be
saved, we populate the error message ourselves. Since there's nothing
custom here, it does not need to use the error saving mechanism.

Add OpenSSH support

Handle custom paths for OpenSSH.

This helped when troubleshooting issues running the `ci/test.sh` script
locally.

Callers can specify the ssh command to invoke using `core.sshcommand` or
the `GIT_SSH` environment variable. This is useful for specifying
alternate configuration, and is particularly useful for our testing
environment.

Provide both cmdline-style handling (passing it to the shell on POSIX,
or directly to CreateProcess on win32) and execv style (passing it
directly to execv on POSIX, and mangling it into a single command-line
on win32).

Don't capture stderr, optimize for the CLI case.

Provide more user-friendly error messages in smart protocol negotiation
failures.

Provide a mechanism for callers to read from stderr.

Suppress SIGPIPEs during writes to our piped process. On single-threaded
applications, this is as simple as ignoring the signal. But since this
is process-wide, on multi-threaded applications, we need to use some
cumbersome `pthread_sigmask` manipulation.

Thanks to https://www.doof.me.uk/2020/09/23/sigpipe-and-how-to-ignore-it/
and http://www.microhowto.info:80/howto/ignore_sigpipe_without_affecting_other_threads_in_a_process.html

Instead of "early EOF", provide information on _when_ we're seeing the
EOF for debugging.

A transport may want to validate that it's in a sane state; when
flushing on close, don't assume that we're doing an upload-pack; send
the correct direction.

Now that we (may) exec a child process to do ssh, we don't want valgrind
reporting on that. Suppress children in valgrind runs.

There are no custom callbacks for OpenSSH; don't test them.