Success case:
- the path endpoint creates and sends a LR_StatusMessage upon
successful path creation
Failure case:
- an intermediate hop creates and sends a LR_StatusMessage upon
failure to forward the path to the next hop for any reason
Both cases:
- transit hops receive LR_StatusMessages and add a frame
to them reflecting their "status" with respect to that path
- the path creator receives LR_StatusMessages and decrypts/parses
the LR_StatusRecord frames from the path hops. If all is good,
the Path does as it would when receiving a PathConfirmMessage.
If not, the Path marks the new path as failed.
LR_StatusMessage is now used/sent in place of PathConfirmMessage
This commit refactors functionality from the Router class into separate,
dedicated classes.
There are a few behavior changes that came as a result of discussion on
what the correct behavior should be.
In addition, many things Router was previously doing can now be provided
callback functions to alert the calling point when the asynchronous
action completes, successfully or otherwise.
lto stuff remains for now
since native builds work
(cherry picked from commit 37814472af5e7c35d514bae16d19b08050765d52)
i'm not porting the UNIX-tier cppfs thing
(cherry picked from commit d6edbd789534d4fd0bce6c8c2418347cd80bebdb)
none of this had to be specified directly ffs
(cherry picked from commit 5dbefa7131a6fe0b2006c90ecdba7e466fdd1ecc)
stop breaking shit reee
(cherry picked from commit 14be89902ccc75a7fc21863593da393ca976d0d4)