Decode replies using actual received length

[aisk]

When decoding replies, the code previously passed the whole 2048-byte zero-filled buffer instead of slicing it to n, the number of bytes actually returned by recv_from. This changes all three decode paths to use &buffer[..n]: bare IPv4 ICMP, IPv4 with IP-header stripping, and IPv6.

As a result, the inner ICMP length extracted by IpV4Packet::decode reflects the real packet length rather than including trailing zero padding. Combined with the previously tightened length check in EchoReply::decode, short or malformed replies now return InvalidSize and get skipped by the loop, instead of having a bogus payload read out of the zero padding. The n == 32 branch still holds, since a RAW reply always carries an IP header and is therefore at least 52 bytes, so it can never be mistaken for the bare-ICMP branch.