Add robusteness against values of variables being reset too quickly on the OPC UA server.

[AlainBertemes]

Setup
OPC UA server running on a SIMOTION D
EPICS device support module for OPC UA using the open62541 SDK running on an industrial PC (on Windows)
o All EPICS PVs are linked to a 100ms OPC subscription
o Some variables on the OPC server are foreseen to have write access from both sides, i.e. the operator can write to them using EPICS, but the SIMOTION can also write to them
o On EPICS side, these variables are outputs (mainly ao and bo) and have the SCAN field set to “Passive”
o In the EPICS PV definition, no options (such as sampling or timestamp) were defined for the OUT field, so the behavior is the default one (e.g. sampling interval = publishing interval, timestamp = server)

Is your feature request related to a problem? Please describe.
For the variables with write access from both sides, if the SIMOTION sets their value back to their previous value too quickly, this setback is not propagated back to the EPICS side. The related EPICS PV keeps the value which was set via EPICS while the value of the related variable on the OPC server has been set back to its old value, creating a mismatch between the EPICS and OPC sides.

It seems like the following is happening:
• Initial value of the variable on the OPC UA server: A
• An EPICS command is send to set the value to B
• The value on the OPC server is B, but only for a very short time until it is reset to A. Between the acceptance of B on the OPC server and the reset by the PLC to value A by the PLC, there is no cycle of the IOC’s OPC subscription
• During the next cycle of the IOC’s OPC subscription, the IOC reads back OK as a return value, but does not see any update of the value on the OPC server (as that value has already been set back to A by the PLC).
• As a result of the return value being "OK", the IOC nonetheless keeps value B.

Describe the solution you'd like
Addition of a verification mechanism to make sure that, after the write request returns ok, the value of the variable on the OPC UA server is equal to the value in the linked EPICS PV and no updates/set backs of the variable are missed:
• send new value as part of the write request
• if the write request returns error, update the record to the last received value, record status = write error
• if the write request returns ok, flag the item as "change pending" and set up a timer for 1.2 * publishing_period on incoming updates
o if there's a new value for the record, put it in the per-record queue, if "change pending": reset "change pending" and cancel the timer
• when the timer expires, if the value has "change pending", set the record to the last received value and reset "change pending"