remove expanded flag when return Nodes or NodeID

[huskar-t]

when returning Nodes or NodeID there is no longer NamespaceURI and ServerIndex information so the expanded flag should be removed

[huskar-t]

I think this is the reason for #550.
ReadRequest.NodesToRead[*].NodeID and BrowseRequest.NodesToBrowse.NodesToBrowse[*].NodeID contain the expanded flag and therefore cause the request error.
@magiconair

[huskar-t]

@kung-foo @magiconair Please review

[kung-foo]

I think I took a look at this a few years ago. See #200 (comment)

The reason I never merged it was because I am reluctant to just internally clear flags. I would need to know that that there is never a case where the flags should be set.

[huskar-t]

@kung-foo
In the ReferencedNodesWithContext method

for _, r := range res {
		r.NodeID.NodeID.RemoveExpandedFlag()
		nodes = append(nodes, n.c.Node(r.NodeID.NodeID))
	}

where r.NodeID is the ExpandedNodeID returned in the prosys simulator with the ServerIndex flag. So r.NodeID.NodeID is returned with the ServerIndex flag.
In the AttributesWithContext function

	for _, id := range attrID {
		rv := &ua.ReadValueID{NodeID: n.ID, AttributeID: id}
		req.NodesToRead = append(req.NodesToRead, rv)
	}

if n.ID with ServerIndex flag.The nodeID Encode method writes the mask directly to it, which sends an incorrect ReadRequest

func (n *NodeID) Encode() ([]byte, error) {
	buf := NewBuffer(nil)
	buf.WriteByte(byte(n.mask))

In the browse example, the error occurs as follows:
1.

refs, err := n.ReferencedNodesWithContext(ctx, refType, ua.BrowseDirectionForward, ua.NodeClassAll, true)

ReferencedNodesWithContext return nodes with ServerIndex flag
2.

attrs, err := n.AttributesWithContext(ctx, ua.AttributeIDNodeClass, ua.AttributeIDBrowseName, ua.AttributeIDDescription, ua.AttributeIDAccessLevel, ua.AttributeIDDataType)

An incorrect ReadRequest was sent

[huskar-t]

I think if the return contains NodeID but not ExpandedNodeID, then the expanded flag of NodeID should be cleared

[huskar-t]

@magiconair @kung-foo Is this pull request rejected?

[huskar-t]

maybe you can use prosysopc simulator to try to browse

[kung-foo]

@huskar-t These changes can take time to merge since we have very few e2e integration tests to verify that this doesn't break expected behavior. I don't have much time this week, but will probably get a chance next week.

[huskar-t]

@kung-foo Any progress?

[huskar-t]

@magiconair @kung-foo If there are any issues or concerns about my code, please do not hesitate to let me know. I am happy to work on any necessary changes or improvements to get it merged.

[sruehl]

I think the analysis from @huskar-t is correct. I attached some wireshark screenshot in #682 which illustrates the problem.

[kung-foo]

Fixed in #683