Make the TPZipper latency < TAZipper latency to avoid tardy sets

[philiprodrigues]

This PR reduces the latency timeout of the TPZipper to ensure it's less than the timeout for the TAZipper downstream. Reasoning given below. Along with DUNE-DAQ/trigger#133 , this PR solves the "Tardy sets" warnings we've seen with pre-v3.0.0.

The max_latency_ms of the TPZipper should be
kept smaller than the corresponding value in the
downstream TAZipper. The reason is to avoid tardy
sets at run stop, which are caused as follows:

1. The TPZipper receives its last input TPSets from
   multiple links. In general, the last time received
   from each link will be different (because the
   upstream readout senders don't all stop
   simultaneously). So there will be sets on one link
   that don't have time-matched sets on the other
   links. TPZipper sends these unmatched sets out after
   TPZipper's max_latency_ms milliseconds have passed,
   so these sets are delayed by
   "tpzipper.max_latency_ms"

2. Meanwhile, the TAZipper has also stopped
   receiving data from all but one of the readout units
   (which are stopped sequentially), and so is in a
   similar situation. Once tazipper.max_latency_ms has
   passed, it sends out the sets from the remaining
   live input, and "catches up" with the current time

So, if tpzipper.max_latency_ms >
tazipper.max_latency_ms, the TA inputs made from the
delayed TPSets will certainly arrive at the TAZipper
after it has caught up to the current time, and be
tardy. If the tpzipper.max_latency_ms ==
tazipper.max_latency_ms, then depending on scheduler
delays etc, the delayed TPSets's TAs may arrive at
the TAZipper tardily. With tpzipper.max_latency_ms <
tazipper.max_latency_ms, everything should be fine.

[dingp]

LGTM

[dingp]

Put the PR into draft until we are post-3.0 release cycle.