Support for Canonical UPER or more strict UPER decoder

[zhouxt1]

The pycrate UPER decoder currently accepts several forms of non-canonical encodings. While this provides flexibility, it prevents users from using the library to validate strict protocol compliance. This feature request proposes adding an option to enforce canonical rules.

The following are specific cases where the decoder is currently lenient:

Unconstrained INTEGER Encoding

• Rule: Per ITU-T X.691 (11.3.6), an unconstrained integer must be encoded using the minimum number of octets.
• Observed Behavior: The decoder accepts integers with redundant leading octets (e.g., 0x02 0x00 0xFF for the value 255, instead of the canonical 0x01 0xFF).

Explicit Encoding of DEFAULT Values

• Rule: Per X.691 (19.5), the encoding for a component with a DEFAULT value must be absent if its value is the default for a simple type.
• Observed Behavior: The decoder accepts messages where a simple type's default value is explicitly encoded rather than omitted.

Empty Extension Groups

• Rule: Per X.691 (19.9), if an extension bit is set to 1 in the bitmap, but all components within the corresponding extension group are absent, the encoding is non-canonical. The extension bit should have been 0.
• Observed Behavior: The decoder accepts a message where an extension bit is 1 but the extension group is effectively empty.

Other things include alternative encodings for length determinant or issue #36. These behaviors allows the parser to accept alternative encodings that are not valid. While it might not have an immediate impact, it is worth noting it.

---

Possible Solution

To address these issues, I suppose pycrate can add strict or canonical flag to the decoder functions, which allows for a more strict or lenient decoding, based on the choice of the user.