[Unsttopabull]

Summary

Adds a ValueType property to MQTTJSONDecoderFB that fixes the sample type of numeric values. Until now the decoder took the type from each message: a whole number was decoded as Int64 and a decimal as Float64. A publisher that writes whole numbers without a decimal point, as JavaScript's JSON.stringify does, changed the signal's descriptor whenever the value crossed one. A client that rebuilds its acquisition on a descriptor change restarted on every switch. This was seen in DewesoftX.

Changes

• ValueType property (Auto / Float64 / Int64), default Float64:
  • Float64 converts every number, so the sample type stays the same.
  • Int64 accepts whole numbers only. 22.0 is decoded as 22. A fractional value fails to parse with a status error instead of being truncated.
  • Auto keeps the previous behaviour.
  • String values are not affected.
• MqttDataWrapper: a new convertValueType step runs after the value is extracted and before the packets are built.
• Docs and tests: the README describes the property. New tests cover Float64 across whole numbers and decimals, an integer array under Float64, Auto, and Int64 accepting 22.0 and rejecting 21.5. The Float64 and Int64 tests fail without the conversion (checked on our fork, which has the same decoder code). The existing integer tests now set Int64, and DataTransferIntArrayIsNotPromoted sets Auto.

Notes

• Behaviour change: decoders that receive whole numbers now publish Float64 by default instead of Int64. Integers above 2^53 lose precision unless the decoder is set to Int64.
• Decoders created from the subscriber's JSON config get the default. The JSON config has no key for the value type.

Testing

• Built in Release with MSVC on this branch. With a local Mosquitto broker, test_mqtt_stream_module passes all 202 tests and test_mqtt_streaming_protocol all 25.