Sparkplug seqNo can be null which is against the specification

[Mattias Isegran Bergander]

This issue "SparkplugBPayloadDecoder should use a Long rather than a primitive long so it can be null" #154 is in contradiction with the sparkplug and protbuf specification. Along with the associated pull request that I think should be retracted: #155

The TCK tests this correctly by only checking the value of NBIRTH messages for example, which is always 0, and will not be transferred in protbuf implementations as it is 0 and will default to it anyway.

This is causing issues between versions of clients and different implementations in the field.

Primitives in protobuf can't be null, if the seq is not sent it is 0.
seq is defined as:

optional uint64 seq = 3; // Sequence number

Protobuf has this very well defined. It’s not null.

This section explains it well:

“A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, accessing the corresponding field in the parsed object returns the default value for that field. The default value can be specified as part of the message description.”

“If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bytes, the default value is the empty byte string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum’s type definition. “

From:
https://protobuf.dev/programming-guides/proto/#optional