establishment_timeout on initiator is missing the per-hop term

[ronandi]

This is just a heads up. I noticed this while working on something and thought I would call it out in case it would be helpful:

On the initiator side, establishment_timeout never gets the per-hop term added, so it's just the first-hop timeout regardless of path length. The responder side does it right; the initiator doesn't

src/Link.cpp, initiator branch:

_object->_expected_hops = Transport::hops_to(_object->_destination.hash());
_object->_establishment_timeout = Reticulum::get_instance().get_first_hop_timeout(destination.hash());

Upstream Python does this (Link.py):

self.establishment_timeout  = get_first_hop_timeout(dest)
self.establishment_timeout += ESTABLISHMENT_TIMEOUT_PER_HOP * max(1, hops_to(dest))

The += is just missing here. _expected_hops even gets computed on the line above and then nothing uses it. Responder path (~L205) already adds the per-hop term like Python

It doesn't actually matter rn, since nothing reads _establishment_timeout and start_watchdog() is a stub:
__watchdog_job is commented out, and Transport::jobs() only reaps already-closed links and retries stuck HANDSHAKEs. Whenever/if the watchdog is wired up, a multi-hop initiator will only get the first-hop budget and give up early.

_object->_establishment_timeout += Type::Link::ESTABLISHMENT_TIMEOUT_PER_HOP
                                 * std::max((uint8_t)1, _object->_expected_hops);

(on 83b8814)

---

Unrelated, just an FYI in case it's useful when you do the watchdog: upstream has an open item about reworking rngit's timeouts ("Use intelligent timeout handling instead of dumb timeouts", workdoc #1 / #41). a8d24177d946de4f1f0a0fe1af9a1338:/page/work_doc.mug=reticulum|r=reticulum|id=1|scope=active` . Possibly on a different layer than this, but thought I would note it.