MT compatibility for hooks
The idea is to create a new entry point for all hooks (currently named "mt_compatible") and to add documentation in the hook developer's guide.
Details about the first point:
- by default (i.e. when the function is not implemented) mt_compatible returns int 0
- int 0 means the hook is not compatible with multi-threading. The action e.g. refuse to load the hook library or disable MT with a warning is yet to be decided. Currently I suppose the second.
- a new hook library function will return the minimum value of mt_compatible over all hooks
Details about the second point:
- the new mt_compatible will be described
- this is for DHCPv4 and/or DHCPv6 server hooks only for now
- returning something not 0 means the hook is compatible with MT (not exhaustive list):
- it does not change server state e.g. change config or modifying a lease without stopping threads
- for all callouts called by packet processing (e.g. pkt* and lease*) the hook entry point must be reentrant
- commands must be reentrant (note that currently commands are not run in parallel but this is a provision for future evolutions)
- all methods of host manager or similar service must be reentrant
- the way (API) to stop threads should be added but until it is defined perhaps we can go with a place-holder.