DHCP hook libs should not be loadable by CA,D2

Currently, it's possible to load hooks libraries both in the CA and in the various services, irrespective of where they are intended to be installed and used.

The ability to install hooks everywhere adds huge flexibility to Kea DHCP and is a wonderful feature, but at the same time, it demonstrates one variant of Murphy's law quite beautifully - if something can be installed in the wrong place, then it will be..

Then, looking ahead to the future possibility that we might one day have hooks that could be genuinely installed on both the CA and on one or more services, so that the administrator can choose where to send the commands to be executed - this is simply not possible at the moment because of the order of precedence that is being applied:

In section 16.1, describing the reason why you need to specify 'service', is written:

https://kea.isc.org/docs/kea-guide.html#ctrl-channel-syntax

service is a list of the servers at which the control command is targetted. In the example above, the control command is targetted at the DHCPv4 server. In most cases, the CA will simply forward this command to the DHCPv4 server for processing via unix domain socket. Sometimes, the command including a service value may also be processed by the CA, if the CA is running a hooks library which handles such command for the given server. As an example, the hooks library attached to the CA may perform some operations on the database (like adding host reservations, modifying leases etc.). An advantage of performing DHCPv4 specific administrative operations in the CA rather than forwarding it to the DHCPv4 server is the ability to perform these operations without disrupting the DHCPv4 service (DHCPv4 server doesn't have to stop processing DHCP messages to apply changes to the database). Nevertheless, these situations are rather rare and, in most cases, when the service parameter contains a name of the service the commands are simply forwarded by the CA. The forwarded command includes the service parameter but this parameter is ignored by the receiving server. This parameter is only meaningful to the CA.

This sounds really good and useful, and I can imagine future use cases where you might design a multi-purpose hook that could run either from the CA or from a specific service - perhaps database manipulation as suggested, or something to do with stats?

But here's where the restrictiveness bites - because: https://kea.isc.org/docs/kea-guide.html#agent-overview

The CA processes received commands according to the following algorithm:

• Pass command into any installed hooks (regardless of service value(s)). If the command is handled by a hook, return the response.
• If the service specifies one more or services, the CA will forward the command to specified services and return the accumulated responses.
• If service is not specified or is an empty list, the CA will handle the command if it supports it.

That first action in the order of precedence prevents any command that could be executed either on the CA via an installed hook, OR on another service, from ever being forwarded to the specified service.

(This first action in the order of precedence is also why ticket https://kea.isc.org/ticket/5613#ticket is important - because any hooks libraries loaded by mistake on both the CA and the service for which they were intended, will consume any commands sent to the CA that should be forwarded - very confusing and frustrating for new hooks users).