Implement plugin support for resolving domain names

[handicraftsman]

Just a sketch PR to add plugin support into the library.

Just as a note, I am not a Rust developer - more like Java and Node.js -, so codestyle inaccuracies might be there - feel free to tell me about them.

By the way, what is the current state of the testing infra, is that required, recommended, or done on the "best-effort" principle here?

This PR is inspired by a feature I am trying to build in a tiny pet project I have - mDNS publisher for LXC containers which are running on my home lab.

[handicraftsman]

Should've run rustfmt before creating this PR 🤦🏻, completely forgot about it

[keepsimple1]

Thank you for your PR! I will take a look in the next two days. And for your question:

By the way, what is the current state of the testing infra, is that required, recommended, or done on the "best-effort" principle here?

It is required ;-). We don't have 100% code coverage in tests, but we want to make sure every new feature or bugfix is covered by some test.

[handicraftsman]

Yeah, thanks for replying.

I also noticed some bad pieces of code I made, but only after sending this PR, will fix them later today (GMT+2/EET).

An example is how the plugins-provided serviceinfos are discovered - I am doing lots of copying there, will fix that. (I am too used to by-reference variables like in Java, did not notice that while implementing)

[handicraftsman]

Pushed some improvements, added a test for this new feature.

Should be in reviewable state now.

[handicraftsman]

Oh, LazyCell is not yet available in this Rust version. Will fix.

[keepsimple1]

This PR is inspired by a feature I am trying to build in a tiny pet project I have - mDNS publisher for LXC containers which are running on my home lab.

Could you please elaborate the use case? (No need to give any private info, but please provide as much details as possible). I am trying to understand if such a plugin infra is what we'd like to support the user case you have.

[handicraftsman]

Well, the most exact reason is that tracking LXC-specific events to track the running containers is not as easy (more like, I haven't heard of that) as just doing lxc ls, which outputs readable JSON if configured for that.

I mean, I can do lxc ls periodically, and then incrementally reconfigure mdns-sd based on that, but pull model implemented in this PR seems simpler here than push model that is the alternative.

[keepsimple1]

I mean, I can do lxc ls periodically, and then incrementally reconfigure mdns-sd based on that, but pull model implemented in this PR seems simpler here than push model that is the alternative.

Will each LXC container run a mDNS server to publish a service? What info would you "reconfigure" mdns-sd? IP address, or something else?

[handicraftsman]

LXC containers can have dedicated IP addresses on interfaces when this is explicitly allowed.
And lxc ls output returns these addresses, so that these can be pointed to by an mdns-sd based service.

[handicraftsman]

So there are two approaches now - one is hosting mdns inside these containers, and the other one is using a host-machine-side daemon for that

[keepsimple1]

If I understand, the requirement here is: as LXC container IP address might change overtime, you want to be able to resolve domain names to the current IP address, not necessary the IP address passed in ServiceInfo.

(If I mis-understood, please correct me)

For this, we support ServiceInfo::enable_addr_auto that detects IP address changes on interfaces. If you want only specified interfaces, you can apply disable_interface(IfKind::All) and then use ServiceDaemon::enable_interface . Would that solve your problem without using a plugin infra? If not, I wanted to know what's missing and if make sense to enhance these APIs to support missing cases.

[handicraftsman]

Hmmm.

What if a container is added or removed in runtime?

Yes, in these cases I can theoretically do some minimal diffing, although I am not sure which approach is better - plugin-based approach allows going without diffing, just by listing all available services, while diffing requires implementing more complex logic on the consumer side.

[keepsimple1]

What if a container is added or removed in runtime?

What is the main concern? Suppose you have mdns-sd daemon Foo runs as a service in a container A. What will be your main concern when A is added or removed?

Yes, in these cases I can theoretically do some minimal diffing, although I am not sure which approach is better - plugin-based approach allows going without diffing, just by listing all available services, while diffing requires implementing more complex logic on the consumer side.

Did you mean the main issue is: how does a client deal with a service running in a LXC container come and go when the container comes and goes? Is this similar with the issue #54 , i.e. a better detection of service removed? (note that currently ServiceRemoved is sent to a client when a service record expired and evicted. But issue #54 basically asks for a quicker detection, which is still on my plate.)

[keepsimple1]

Just a follow up, issue #54 is resolved now with a new ServiceDaemon::verify() API. Would that help your case?