Disable Time Port calls when TlmPacketizer is being used

[timcanham]

The FPP autocoder generates Fw.Time calls for components that contain telemetry channels. Then the Fw.Tlm output port is called with the value and the time tag.
Svc/TlmChan puts the telemetry, including the time tag, in a packet and sends it to the ground. The ground software uses the time tag to display the measurement time.
Svc/TlmPacketizer discards the time tag, and puts the telemetry into the destination packet at the specified offset. On each scheduler call, Svc/TlmPacketizer checks each packet to see if there are new updates to any of the channels. If there are, the packet will get a packet-level timestamp.
So, in essence, when Svc/TlmPacketizer is used, all the component time port calls are useless. It would be nice to have a global way to turn off the component time calls so all those CPU cycles are not wasted.

[timcanham]

@bocchino and I talked about options:

1. Have an FPP directive at the project level that causes the autocoder to not generate the call to the time ports in the component.
2. Have TlmChan/TlmPacketizer or other telemetry component add the time stamp, not the components as a permanent change to the autocode. Then TlmPacketizer can skip the call while TlmChan can make it.
3. ?

[zimri-leisher]

2. seems like the better option. The only problem is that now the timestamp would be the time the tlm is received in TlmPacketizer and not the time it is sent from the component. There could be some small delays associated with mutex locks there.
   It might also be annoying to allow the user to continue to manually specify a tlm time, like they can do now.

What is the performance hit for calls to getTime?

[LeStarch]

I would push back against this change. F´ is designed such that the behavior of a component is independent of what it connects to. This change would break that property.

Solution 1 could easily break packet logging. A typical pattern is to fork telemetry into a log and into the downlink with packetizer. This solution will invalidate logging at this level.

Solution 2 will break projects that need telemetry time stamps as close to the source of truth as possible. We put in a component time override for this very purpose. Moving that time to some other component would hard-break the ability for projects to use the channel time as a source of true time.

The only solution I see would be to have a global build switch of the form "DISABLE_COMPONENT_TIME" and have that determine if the autocoding puts in getTime automatically or not. Then the entire system would be subject to this constraint. However, I still dislike this solution because:

1. Telemetry representations are now bimodal
2. Autocoder inputs need to be updated to respond to the switch
3. All down-stream tooling now breaks and must be updated to be bimodal.
4. Use of components dependent on telemetry time now break.

This change would require a lot of architectural changes to support a modest optimization. Is there something driving this request or some known area where this overhead is insufficient?