fsck: inspect tag objects more closely

We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.

In preparation for being able to check tag objects that are just being
received, the fsck_tag_buffer() function accepts a pointer to the raw
tag object (but falls back to calling read_sha1_file() if that pointer
is NULL).

This work was sponsored by GitHub Inc.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add regression tests for stricter tag fsck'ing

The intent of the two new test cases is to catch general breakages in
the fsck_tag() function, not so much to test it extensively, trying to
strike the proper balance between thoroughness and speed.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Refactor out fsck_object_buffer() accepting the object data

When fsck'ing an incoming pack, we need to fsck objects that cannot be
read via read_sha1_file() because they are not local yet (and might even
be rejected if transfer.fsckobjects is set to 'true').

For commits, there is a hack in place: we basically cache commit
objects' buffers anyway, but the same is not true for tag objects.

By refactoring fsck_object() to take the object buffer as an optional
argument, we prepare the machinery for the upcoming handling of tag
objects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure that index-pack --strict fails upon invalid tag objects

One of the most important use cases for the strict tag object checking
is when transfer.fsckobjects is set to true to catch invalid objects
early on. This new regression test essentially tests the same code path
by directly calling 'index-pack --strict' on a pack containing an
invalid tag object.

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