Thanks for your contribution! Before going into more code-specific reviews I have a few questions about the intent / setup:

• How are the configuration files created?
  One thing I want to avoid is for people to use the file plugin and fsnotify to implement dynamic backends, and instead have proper plugins that reach out to said backend directly when possible. If these files are not manually edited we could look for a more direct plugin integration

• The VSS option is defined for both DHCPv4 and DHCPv6. Can your approach work for DHCPv6?
  We want all plugins for options that have an equivalent in DHCPv6 to have DHCPv6 support and will generally avoid merging a DHCPv4-only plugin. That work doesn't need to be done upfront or right now but we'll want it at some point

• While the file format for configuration is different, a lot of this functionality is redundant with the file plugin as noted. I feel that they could share more code and maybe just have 2 different configuration syntax for the same plugin (and you could treat no relay info the same way as VSS id 255).
  Have you tried something of the sort and if so were there issues doing so?

Codecov Report

Attention: Patch coverage is 73.86364% with 23 lines in your changes missing coverage. Please review.

Project coverage is 44.54%. Comparing base (bd8c808) to head (12f63d4).
Report is 14 commits behind head on master.

@@            Coverage Diff             @@
##           master     #195      +/-   ##
==========================================
+ Coverage   42.62%   44.54%   +1.92%     
==========================================
  Files          24       26       +2     
  Lines        1342     1430      +88     
==========================================
+ Hits          572      637      +65     
- Misses        679      696      +17     
- Partials       91       97       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hi, @Natolumin

First of all, thanks for looking into this PR.

How are the configuration files created?
One thing I want to avoid is for people to use the file plugin and fsnotify to implement dynamic backends, and instead have proper plugins that reach out to said backend directly when possible. If these files are not manually edited we could look for a more direct plugin integration

You may create a predefined file and load it on app startup or create some empty file and populate it in runtime. We're using it to dynamically configure DHCP leases in runtime by our external control-plane service (some kind of sdn agent).

The VSS option is defined for both DHCPv4 and DHCPv6. Can your approach work for DHCPv6?
We want all plugins for options that have an equivalent in DHCPv6 to have DHCPv6 support and will generally avoid merging a DHCPv4-only plugin. That work doesn't need to be done upfront or right now but we'll want it at some point

Unfortunately, we're not using DHCPv6 now + it looks like adding support of the same functionality for DHCPv6 requires some additional work to be done in https://github.com/insomniacslk/dhcp. Btw, I'm not sure that DHCPv6 supports 151 suboption - https://www.rfc-editor.org/rfc/rfc6607.html#section-3.4. So it requires some investigation.

While the file format for configuration is different, a lot of this functionality is redundant with the file plugin as noted. I feel that they could share more code and maybe just have 2 different configuration syntax for the same plugin (and you could treat no relay info the same way as VSS id 255).
Have you tried something of the sort and if so were there issues doing so?

I agree, that vss plugin looks very similar to the file plugin, but:

1. I don't like the idea of having two different configuration syntax for the same plugin, it may be confusing
2. file plugin is very simple - it holds MAC <--> IP mapping, while we need some additional DHCP options, such as lease duration or dns servers

"Teaching" all other plugins (mask, lease etc.) to work with multiple vss may be a better idea, but it seems too complicated, so that I decided just to implement a separate plugin for such functionality.

The VSS option is defined for both DHCPv4 and DHCPv6. Can your approach work for DHCPv6?
We want all plugins for options that have an equivalent in DHCPv6 to have DHCPv6 support and will generally avoid merging a DHCPv4-only plugin. That work doesn't need to be done upfront or right now but we'll want it at some point

Unfortunately, we're not using DHCPv6 now + it looks like adding support of the same functionality for DHCPv6 requires some additional work to be done in https://github.com/insomniacslk/dhcp. Btw, I'm not sure that DHCPv6 supports 151 suboption - https://www.rfc-editor.org/rfc/rfc6607.html#section-3.4. So it requires some investigation.

In any case there will be changes to make to the DHCP library to support parsing the actual option/suboption and its format: https://www.rfc-editor.org/rfc/rfc6607.html#section-3.5 . The current code just interprets it as a string which surely works for your internal purposes but wouldn't be ok for coredhcp in general.
Fortunately, the dhcp library has essentially the same maintainers as this server, we can definitely get those changes in there :)

As for DHCPv6, while it doesn't separate options and suboption types and the option is encoded in the relay-forward/relay-reply message instead of the relay-agent option, otherwise it supports roughly the same features

I'm not asking you to do this work unless you want to, but we will want it to be done before merging. When I have some cycles I might try my hand at it

I agree, that vss plugin looks very similar to the file plugin, but:

1. I don't like the idea of having two different configuration syntax for the same plugin, it may be confusing
2. file plugin is very simple - it holds MAC <--> IP mapping, while we need some additional DHCP options, such as lease duration or dns servers

"Teaching" all other plugins (mask, lease etc.) to work with multiple vss may be a better idea, but it seems too complicated, so that I decided just to implement a separate plugin for such functionality.

There's been multiple requests and PRs (#147, #152) to allow more data in the file plugin, and this is essentially the same request with different options to match against and different options to return.
Having a proliferation of slightly different plugins for static configuration/allocation is not desirable, and none of the previous proposals were really acceptable, but at some point we'll need to bite the bullet and make a new file plugin configuration format to support those usecases (and either break the existing one or providing a compatibility layer).
So far, this PR is I think the most versatile format that doesn't try to retrofit into the line-based configuration, so I'd be interested in using it as a base for the new file plugin configuration