Fix: restrict Variable Byte Integer to 24bits

[seriousme]

The MQTT 5.0 specification defines Variable Byte Integer as a maximum of 24 bits. The 3.x spec uses this format for packet length only but in 5.0 it is also used in properties (e.g. subscriptionIdentifier)

Testing generation of a Variable Byte Integer with anything bigger than that resulted in a Attempt to write outside buffer bounds error because numbers.js would allocate 0 bytes and still try to write 4 or more bytes.
Parsing of a Variable Byte Integer (e.g. in packet length) > 24 bits would not emit an error where it should.

This PR fixes that and adds tests to confirm 24 bits maximum.

It also renames the constants and variables used by the parser so they are inline with its intended use again.

Performance should not be impacted because:
a) generator algorithm has been simplified so it should be a tiny bit faster
b) the cache hides the performance of generation anyway :-)
c) the rest of the changes are only small logic updates

Kind regards,
Hans

[mcollina]

Test fails on node 6.

Given we use the same logic for MQTT 3.1.1, would there be compatibility problems?

[seriousme]

Turns out that in Node 6 handles Buffer.subarray different from later versions

Node 6:

> b= Buffer.from([1,2,3,4])
<Buffer 01 02 03 04>
> b.subarray(0,1)
Uint8Array [ 1 ]

Node 8 and later

> b= Buffer.from([1,2,3,4])
<Buffer 01 02 03 04>
> b.subarray(0,1)
<Buffer 01>

Buffer.slice works as well but creates a copy that needs to be allocated and thus costs some performance :-(
Solved now.

Kind regards,
Hans

[seriousme]

As to compatibility :

MQTT 3.1, 3.11 and 5.0 all use the same algorithm with the same 24 bits max (decimal 268,435,455, hex 0x0f ff ff ff) but 3.1 and 3.11 only use it for length and do not name it Variable Byte Integer yet. So no compatibility impact :-)

Kind regards,
Hans

[mcollina]

lgtm