Fix Git pack-file parsing issue

[nikita-tkachenko-datadog]

What Does This Do

This change fixes an issue that happens when parsing some Git pack-files.
Currently the logic reads Git object size from the pack file, then reads the number of bytes equal to that size, then decompresses the data that was read.
The problem is that the number that's being read in the first step is the size of the Git object AFTER decompression.
So the second steps reads more bytes than it needs, which is fine in most cases, as decompression stops once the end of the compressed data has been reached.
This is a problem, however, when the Git object is located at the end of the file - in that case the logic tries to read more bytes than there are available, and fails with an error.
The quick fix is to stop reading once the end of the file has been reached.

Motivation

Because of this issue, Git metadata cannot be extracted for some repositories (one example is Mybatis-3, which was used for testing and uncovered this issue).

[smola]

If I understand the issue correctly, while this PR fixes the issue with end of file, the byte buffer allocated here is generally much larger than needed?

[nikita-tkachenko-datadog]

If I understand the issue correctly, while this PR fixes the issue with end of file, the byte buffer allocated here is generally much larger than needed?

Correct, the size of the buffer is equal to the size of the decompressed object, while the data that we read into it is the compressed object.

It is a quick-and-dirty fix, but fixing this "properly" would require much more changes in the code (which originally was not written by us, but ported from an opensource library).

I wouldn't say that allocating a larger buffer is much of an issue here - the buffer size is typically around 1KB, and we do this parsing only once during agent startup