Add clock servo parameters to gPTP clock synchronization

[levy]

This issue was created by extracting the relavant parts of #837 issue.

Upon further investigating the IEEE802.1AS-2020 standard there is no single way of synchronising a clock, thus the current method of setting the new clock time is valid. The introduction of a clock servo can be a good future alternative for clock synchronisation. This would have the clock drift rate value be the only value that changes with a synchronisation method such as pi or linear regression. LinuxPTP (ptp4l) implements such a servo.

The describe clock servo could even be an optional mode of operation of the Gptp module. So instead of setting the clock time at the current synchronization point, Gptp would overshoot the oscillator compensation factor in a way that causes the slave clock to catch up with the master clock by the time of the next synchronization point.

Having servo options would prove very useful, particularly for comparison to real world deployments of gPTP. Several servo types could be made available as options (eg. none, pi, linear, etc). A good point of reference for its implementation could be ptp4linux, the servo.c file contains all of their setup. This tool is commonly used and thus can be considered a good reference point. Implementing this into OMNeT++/INET would also allow for the simulation of the servo type and its parameters and thus the selection of the most applicable values to achieve a desired behavior for real world use.

If the clock servo is implemented as proportional integral (PI) controller it would be nice to be able to configure

The proportional- and integral gain parameters for the PI controller.
A threshold for the clock error. If the threshold is exceeded the local time is set directly to the grandmaster's time (phase jump). In the first synchronization interval after the start-up the clock error might be too large to be compensated by a controller in a reasonable amount of time, because in off-the-shelf processors there are some limitations how fast/slow dynamic clock dividers can be configured.