Enable DirectMethods to be able to update many OPCNodes

[steffenbeermann]

Is your feature request related to a problem? Please describe.
We would like to use the DirectMethods from the publisher (https://azure.github.io/Industrial-IoT/opc-publisher/directmethods.html) to configure the endpoints of our publisher. We have multiple endpoints with up to 20.000 OPC Nodes each. When adding OPCNodes of one connection with the DirectMethods there is currently no way of doing this when the payload is to big for the DirectMethod (because it has to many OPCNodes).

We tried using PublishNodes_V1: This will delete all other configured endpoints on the publisher, but we are able to use a batch approach to configure all OPCNodes of one Endpoint with calling the PublishNodes_V1 DirectMethod multiple times with batches of the whole OPCNodes we want to configure.

We tried using AddOrUpdateEndpoints_V1: With this we can edit only one Endpoint without affecting others, but because we can not pass all OPCNodes in one DirectMethod call, and we want to store all OPCNodes of one Endpoint in one DataSetWriterGroup we overwrite them with each new DirectMethod call when try to batch them.

Describe the solution you'd like
Have an DirectMethod to just add new OPCNodes to an (existing) Endpoint / DataSetWriterGroup.
Describe alternatives you've considered

We could use multiple DataSetWriter but this would create a lot of subscription, which some OPC UA Servers we want to connect does not support and we generally do not want to handle the DataSetWriters. With the Limit of the DirectMethod payload size, we are able to put about 2000 Nodes in one request.

Currently we create the publishednodes.json manually and replace them on the filesystem. This is not really optimal and we would like to have a process where we use DirectMethods.

We don not have direct HTTP Access to the Device, so we can not use the API directly and are limited to the DirectMethods.

Additional context

[marcschier]

#2262 adds additional api surface to better control the configuration content. It is built around the writer and writer group constructs using the identifiers as well as the dataSetFieldId / nodeId as handles.

Constraints: every writer must be uniquely identifiable inside a writer group using the writerGroupId and dataSetWriterId and must have a unique set of nodes (dataSetFieldId/nodeId), This is different from the existing API, and thus existing API calls should not be mixed, or else errors might be returned when publisher encounters ambiguous situations (e.g., writerGroup/writer pointing to more than 1 entry, which is allowed in the current API surface).

Another constraint is that that when an entry is created, it must have at least 1 node in it, so you cannot create an empty entry and then add nodes. I might fix this, but it has ripples into the existing API surface, so I am deferring this for future.