Implement Path Trace optional feature of IEEE1588-2019

[abower-amd]

Implement the 'Path trace' optional feature of IEEE1588-2019 section 16.2. This feature has two parts, sending and receiving. Either could be implemented independently but it would be desirable to present the two parts together to aid testability and review.

Option to append PATH_TRACE TLV to outgoing Announce messages

Implement the 'Path trace' optional feature of IEEE1588-2019 section 16.2 by appending PATH_TRACE TLVs to outgoing Announce messages, controlled via an instance-scope configuration option to the PTP sync module.

The PORT_COMMUNICATION_AVAILABILITY TLV provides an example of how to add an optional TLV to outgoing announce messages:

• Identifying the TLV: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/constants.h#L335
• Defining the TLV: https://github.com/Xilinx-CNS/sfptpd/blob/master/src/ptp/ptpd2/def/optional/port_communication_capabilities.def
• Packing functions for for TLV: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/dep/msg.c#L2463-L2493
• https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/protocol.c#L3235-L3241

Handle received PATH_TRACE TLVs for current parent.

Example for port communication capabilities:

• Handling the TLV: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/protocol.c#L192-L198
• Processing the TLV: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/protocol.c#L3184-L3219
• Saving the traced clock list: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/ptpd2/datatypes.h#L83-L84 - these are the foreign master records. It is a trade off between space for storing for all foreign masters and accessing later via FMR for selected master or a more complex solution. I suggest doing the former.
• Expand the topology where the clock list for parent nodes is available: https://github.com/Xilinx-CNS/sfptpd/blob/3a4113be8339e85e5fc88dd173433fe8624e0172/src/ptp/sfptpd_ptp_module.c#L2762-L2789 Other than the configuration, this is the only part of the solution which is outside of the ptpd2 fork. The coding standard/convention is slightly different here. The native sfptpd and vendored ptpd2 parts of the application are broadly linked via the ptpd_lib.c and ptpd_lib.h files. The configuration and state objects are incorporated into the sfptpd_ptp_module.c instance state but preferably accessed via accessors in ptpd_lib.