fsck: properly bound "invalid tag name" error message

When we detect an invalid tag-name header in a tag object,
like, "tag foo bar\n", we feed the pointer starting at "foo
bar" to a printf "%s" formatter. This shows the name, as we
want, but then it keeps printing the rest of the tag buffer,
rather than stopping at the end of the line.

Our tests did not notice because they look only for the
matching line, but the bug is that we print much more than
we wanted to. So we also adjust the test to be more exact.

Note that when fscking tags with "index-pack --strict", this
is even worse. index-pack does not add a trailing
NUL-terminator after the object, so we may actually read
past the buffer and print uninitialized memory. Running
t5302 with valgrind does notice the bug for that reason.
t: support clang/gcc AddressSanitizer

When git is compiled with "-fsanitize=address" (using clang
or gcc >= 4.8), all invocations of git will check for buffer
overflows. This is similar to running with valgrind, except
that it is more thorough (because of the compiler support,
function-local buffers can be checked, too) and runs much
faster (making it much less painful to run the whole test
suite with the checks turned on).

Unlike valgrind, the magic happens at compile-time, so we
don't need the same infrastructure in the test suite that we
did to support --valgrind. But there are two things we can
help with:

  1. On some platforms, the leak-detector is on by default,
     and causes every invocation of "git init" (and thus
     every test script) to fail. Since running git with
     the leak detector on is pointless (there are way too
     many false positives), let's shut it off automatically
     in the tests.

  2. When apache runs a CGI, it clears the environment of
     unknown variables. This means that the $ASAN_OPTIONS
     config doesn't make it to git-http-backend, and it
     dies due to the leak detector. Let's mark the variable
     as OK for apache to pass.
transport-helper: initialize debug flag before starting threads

The transport_debug() function uses a static variable to
lazily cache the boolean value of $TRANSPORT_DEBUG. If a
program uses transport-helper's bidirectional_transfer_loop
(as remote-ext and remote-fd do), then two threads may both
try to write the variable at the same time.

We can fix this by initializing the variable right before
starting the threads.

Noticed by "-fsanitize=thread". This probably isn't a
problem in practice, as both threads will write the same
value, and we are unlikely to see a torn write on an "int"
(i.e., on sane platforms a write to an int is atomic).
Avoid accessing uninitialized alt_odb entry data

At the end of link_alt_odb_entry, we replace the trailing NUL of the base
directory by a slash. The idea is that the users will want to append
either the "pack/" directory or the path to a loose object.

However, at least `git prune` wants to access the base directory itself.
Therefore, we need to NUL-terminate after appending a slash to the base
directory, to avoid undeterministic behavior.

Thanks "Valerie" Valgrind!

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When re-executing tests, remember when they were called via `sh -x`

When debugging tests, it is a good practice to call them via `sh -x
t0123-something.sh -i -v`. The `-x` option asks the shell to print out the
commands before executing them.

For some modes, however, we have to re-execute the shell, e.g. when
running with the --valgrind flag. Let's not forget to call the subshell
with the same `-x` flag.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>