EXI Header check is too lax

[barsnick]

Describe the bug

EXI streams beginning with some values other than 0x80, such as 0x01 or 0x40, should not be decoded.

To Reproduce

See the example streams provided here: #99
4084400009690002000000000000000000000000000000000000000000000000008000009c009c9c39393039393939393939393939393930393939020030009d0100150a

Or provided here: #100:
0108008000e203e8040064040604048dc5410201080002

These currently decode as proper V2GTP messages (when using the correct decoder), although their header bits are incorrect.

Anything else?

In ISO 15118-2, section "7.9.1.3 EXI Settings for application layer messages" describes which EXI format to use. (This is reflected in the same section of ISO 15118-20.)

The EXI standard "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)" describes the header in its section "EXI Header".

The combination of these two standards leads to an 8-bit EXI header b10000000 (0x80), unconditionally. The current checks look only at parts of that specification (EXI Cookie, Presence Bit for EXI Options), and fail to check others (Distinguishing Bits, EXI Format Version):

cbexigen/src/input/code_templates/c/static_code/exi_header.c.jinja

Lines 33 to 40 in 123df71

	if (header == '$')
	{
	result = EXI_ERROR__HEADER_COOKIE_NOT_SUPPORTED;
	}
	else if (header & 0x20)
	{
	result = EXI_ERROR__HEADER_OPTIONS_NOT_SUPPORTED;
	}