Consistent way of maintaining statistics in hooks
The issue first discovered in #3125 (closed)
We have no rules nor best practices with regards to maintaining statistics when hooks are in use. For example, a hook library can return DROP
status to the server and the server will drop the packet. This should usually cause an update of the packet drop statistics. I say usually, because there are cases like load-balancing when the packet is ignored because it belongs to other server. In this case we don't want the drop statistic to increase. So, it is clear that there are different reasons for drops and that's why we maintain drop statistics mostly in the hooks, not in the server. However, this seems to be an error-prone practice for several reasons. First of all, it is not documented anywhere that the hooks are responsible for maintaining statistics. Thus, we had issues that, for example, DHCPv4 server didn't up the drop statistics but the DHCPv6 server did. I also found cases that some hooks bumped the drop statistics for some callouts, but not for others. Moreover, we have no tests that would enforce maintaining statistics in the hooks, so if you miss it in review, the statistics will almost surely get outdated.
There are generally two approaches possible. One is to make the hooks responsible for the statistics. Another one is to make the server responsible for the statistics. We pretty much now use the former approach but we really need some ways of ensuring that the hooks are doing a good job. The latter seems to be less error-prone because there will be a single place generating the statistics. It, however, requires some more concise signalling between the hooks and the server, so the server knows what kind of statistics it needs to update when it gets a specific status code. We should take into account existing hook libraries and specific use cases.