feat(opcua.event.subscription): New Plugin to Subscribe to OPCUA Events

[frmoschner]

Summary

This Plugin is useful to subscribe to OPC UA node ids to receive upcoming events on the subscribed nodes.

Checklist

• No AI generated code was used in this PR

Related issues

resolves #16275
replaces #16277

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_arm64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 Click here to get additional PR build artifacts

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz

[srebhan]

Copying your comment from the previous PR regarding my question why this functionality cannot be part of the opcua_listener plugin:

Hi @srebhan,
Thank you very much for your reply!
I have adjusted a few things and created a new pull request #16300.
So far OPCUA Polling & Subscribing is separated from each other, and it would make sense at first sight to merge DataChange Subscriptions (opcua_listener) & Event Subscriptions.
However, in my opinion, the new plugin should not be integrated into the Listener plugin, as a plugin always has a task, and the listener_plugin takes care of the processing of DataChangeNotifcations while the new plugin handles EventNotifications. The structure of the subscription is very different and the listener_plugin uses its own subscribeClientConfig to create client and subscription, which cannot be used for my plugin. So if you were to merge the plugins, you would have to differentiate in many places in the code whether the subscription is a DataChange or an event subscription. I think it is much more user-friendly and easier to maintain if the plugins are separated.
I have seen that there is already an opcua client (plugins/common/opcua/client.go), which I am using from now on. I have removed my own client manager. This means there are no more redundancies in the plugins.

[srebhan]

@frmoschner I do not agree with your argumentation. Looking at the opcua_listener plugin, and more specifically at subscribe_client.go a lot of code looks familiar when checking your plugin. Sure the subscription-response processing need to be different and you would need to add a startStreamEvents function including a handler but that's OK.

You are starting this new plugin and someone will request adding tags to the events, something opcua_listener has. Then people will request workarounds because some strange devices return strange result codes, something opcua_listener has. I can go on with this why it is NOT easier to maintain a separate plugin.
Furthermore, you can reuse a lot of configuration options and subscribe to both events and values at the same time with the same connection.

All this being said, I still do not see a strong argument for a separate plugin!

We can talk about changes to the listener plugins that might be necessary but unless you do not provide a strong argument I like to ask you to merge this functionality into the opcua_listener plugin.