opcua Refactor: zero length variant array decoding

Closes #145

As I was just on the train with a few hours to kill, I took another look at this issue.

In the discussion, @locka99 pointed out that there were problems inferring the type of 0-length arrays. Yet after reviewing https://reference.opcfoundation.org/v104/Core/docs/Part6/5.2.2/ it seems to me that, if the array bits are set, the type id should be there as well, even if the array length is 0. (the code being executed is in a branch where the array bit is set, so the encoding mask as a whole is not 0) So I think the most likely explanation would be for an encoder implementation having gone awry on that part. If this happens now, from_encoding_mask will return VariantTypeId::Empty, which, in my opinion, is okay.

At the very least, this feels much cleaner than my initial idea of returning Variant::Empty from the encoder - which would probably also require some kind PartialEq implementation that can deal with comparisons of Variant::Empty and zero-length arrays.

Dec 28 '21 09:12 milgner

any news on this?

Jun 27 '22 12:06 thedanielhanke

I'm gonna rebase this onto the current master branch and update the MR.

Jun 27 '22 15:06 milgner

Rebased; tests are green locally. Not sure why the Appveyor integration fails? :thinking:

Jul 01 '22 08:07 milgner