Bug: Ipv4Packet::get_total_length() incorrect byte order

[fujiapple852]

The Ipv4 total_length has a platform dependant byte order (see byte_order.rs for details) and therefore this function does not always return the correct byte order:

trippy/src/tracing/packet/ipv4.rs

Lines 75 to 77 in ad1aff2

	pub fn get_total_length(&self) -> u16 {
	u16::from_be_bytes(self.buf.get_bytes(TOTAL_LENGTH_OFFSET))
	}

This in turn can lead to the payload length calculation being incorrect:

trippy/src/tracing/packet/ipv4.rs

Lines 216 to 218 in ad1aff2

	fn ipv4_payload_length(ipv4: &Ipv4Packet<'_>) -> usize {
	(ipv4.get_total_length() as usize).saturating_sub(ipv4.get_header_length() as usize * 4)
	}

This is not causing a real world issue today as, when the byte order is interpreted incorrectly it typically leads to a very large value for total_length but this is harmless as the code takes the minimum of this and the total buffer size.

To fix this we would require access to the calculated PlatformIpv4FieldByteOrder in the latter function, however this is not something we wish to expose to the raw packet modules. Instead we defer the issue to the caller by returning all available bytes after the Ipv4 header and options. This behaviour is also consistent with the behaviour of all other payload methods in the packet modules.