refactor(dpi/bittorrent): single-allocation hex_encode for info-hash render

[0xghost42]

Summary

hex_encode was building one heap-allocated String per byte via format!("{b:02x}") and then collecting them into the final String. A 20-byte BitTorrent info-hash therefore went through 20 intermediate heap allocations on every peer-handshake analyze.

Replace the iterator with a single String::with_capacity(bytes.len() * 2) and a per-byte write!. Writing into a pre-sized String does not reallocate, so the helper now performs exactly one heap allocation per call regardless of the input length. The lowercase {:02x} output contract is unchanged.

Tests

Three regression tests added:

• The exact-size 20-byte info-hash case (the only size BitTorrent uses in the wild) to lock the lowercase, fixed-width output.
• The empty-slice base case.
• A mix of single-digit bytes (0x00..=0x0f) to lock the zero-padding contract that {:02x} provides.

Local checks:

• cargo test --lib — 364 passed.
• cargo clippy --all-targets -- -D warnings — clean.
• cargo fmt --check — clean.

Closes #304

[laundmo]

This PR is lacking any proof that this is a performance gain and or that the compiler does not optimize the current code to a single string write.

[domcyrus]

@laundmo Thanks for your comment, I also think that without a benchmark the perf gain does not stand. On the other hand this does look to be a bit more correct to me.

[domcyrus]

@0xghost42 LGTM!