Review 'reserved' field in header.rs for improved compatibility

[herr-seppia]

Summary

The current Header.rs implementation includes a 'reserved' data field with 2 bytes reserved for future use. While reserving space for future use is acceptable, concerns have been raised regarding the following aspects:

1. The uncommon size of 2 bytes, which may not be sufficient for potential informational fields in the future.
2. Lack of a protocol version field, which could lead to conflicts and decreased network sustainability during future upgrades.

Possible solution design or implementation

The initial rationale behind the 2-byte reservation was to provide flexibility for users to parse the second byte based on changes to the first byte. However, valid concerns have been raised about potential parsing issues for new messages in old versions. To address this, we propose the following solution:

• Reduce the 'reserved' field to 1 byte.
• Utilize the value of this byte to specify the length of the next N bytes to parse (where N is specified in the first byte).

Additional context

This adjustment aims to maintain compatibility during upgrades, ensuring that even older versions can parse the header without fully understanding the content of reserved fields.

[herr-seppia]

To be compatibile with previous library, the reserved field length need to be a 2 bytes len