No Length/Integer Range check for UPER and APER decoders

[zhouxt1]

Hi,

I found that UPER and APER's decoder does not enforce the size constraint. In contrast, the encoder will enforce those constraints.

For example (in the UPER's case), given this ASN.1 message

S1 ::= INTEGER (1..10)

If we give an the generated parser input \xf0, it will accept the input and parse it to 16. But we cannot encode this value and will output

Error: EncodeError { kind: ValueConstraintNotSatisfied { value: 16, expected: Range { start: Some(1), end: Some(10) } }, codec: Uper }

Similar for Sequence-Of,

S2 ::= SEQUENCE (SIZE (1..10)) OF BOOLEAN

A input like \xff\xff\xff\xff\xff\xff will be parsed to a boolean sequence of length 16, but we cannot encode the message with error:
Error: EncodeError { kind: InvalidLength { length: 16, expected: Range { start: Some(1), end: Some(10) } }, codec: Uper }

I have not tested other range constraints like OCTET STRING or BIT STRING but I suspect similar behaviors.

To improve, I think the decoder should enforce these constraint checks to be consistent with the encoders.