Generic client: single sampling scheduler and monitored item fixes

[viacheslauK]

Summary

Replaces the reader thread that each OpcUaMonitoredItemFbImpl used to own with one SamplingScheduler per device, and fixes several monitored-item defects found along the way.

Changes

• SamplingScheduler (new) drives every monitored item of a device from one thread, each item keeping its own deadline.
• DateTime: added OpcUaDataValue::isDateTime(); DateTime values now build a packet and are read as UA_DateTime instead of readScalar<UA_Int64>, including the UtcTime subtype.
• Validation: SamplingInterval rejects negative and above-uint32_t values; reads reject a null value, report a failed packet build, and catch std::exception / ... beyond OpcUaException.
• Tests and docs: new test_sampling_scheduler.cpp; device and monitored-item suites extended; test server publishes .dt and .utc nodes; USAGE.md adds a property reference and walkthrough.

[denise-opendaq]

so everything except TimestampMode can be read only property

[denise-opendaq]

also im not sure that its a great choice to publish user name and password. additionally username and location is existing in "General" property

PropertyObjectPtr config = instance.createDefaultAddDeviceConfig();
PropertyObjectPtr general = config.getPropertyValue("General");
general.setPropertyValue("Username", username);
general.setPropertyValue("Password", password);

[denise-opendaq]

and to get local id you can just type device.getLocalId() so the property just duplicates the functionality

[viacheslauK]

also im not sure that its a great choice to publish user name and password

It is really not a good way but it is not a subject of the PR. Also this will also go away with the introduction of an authentication manager. I would leave Password/Username as is right now.

[viacheslauK]

so everything except TimestampMode can be read only property

All these properties are outside of a device. They are used to create a device but only TimestampMode is displayed as a device property.

[viacheslauK]

and to get local id you can just type device.getLocalId() so the property just duplicates the functionality

LocalId property is used to set a device local Id (before creation)

[denise-opendaq]

u can do

class OpcUaMonitoredItemFbImpl final : public FunctionBlockImpl<IFunctionBlock, ISampledItem>
{
}

[viacheslauK]

It is not a real openDAQ interface. And I don't think we should make it that way.

[denise-opendaq]

I would probably do the simple scheduler where the item set the fn, the scheduler should call, and inside the function should done all checks. if now samples, just return.

and maybe while registering callback get the id of fn (just incremental counter) so than you can remove function. or scheduler which has a queue of tasks, and inside fn you can re register the fn itself