Improve git-pack encode performance.

[Hou-Xiaoxuan]

The current performance of Git pack encoding is poor and takes too long, causing operations like cloning to be excessively slow, as seen in issue #571 . The main time-consuming factor is the zlib compression process.

Possible solutions:

1. Try alternative compression algorithms/libraries.
2. The current encoding is sequential, consider changing it to parallel processing.

[genedna]

@Hou-Xiaoxuan ,

Maby try miniz_oxide, a pure rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code. It builds in no_std mode, though it requires alloc and collections crates.

[el-ev]

Most of the encoding time is spent on compressing, and we can do little about it. Is it acceptable to lower the compression level or add a option for the user to decide it?

mercury/src/internal/pack/encode.rs:encode_one_object:

 let mut inflate = ZlibEncoder::new(Vec::new(), flate2::Compression::default()); // change to flate2::Compression::fast()

edit: git defaults to 6, same with mercury, so the former idea seems bad...

pack.compression
An integer -1..9, indicating the compression level for objects in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not set, defaults to -1, the zlib default, which is "a default compromise between speed and compression (currently equivalent to level 6)."