Finalize Section 8: Sphinx Packet Construction and Handling

[AkshayaMani]

This PR builds on PR #173 and completes the remaining construction and runtime processing logic in Section 8 of the Mix Protocol RFC. It finalizes the last steps of packet construction (Section 8.5.2 step 3. e–f) and introduces the complete mix node handler logic in Section 8.6, including intermediary and exit processing.
It clearly separates construction, role determination, and processing logic.

Changes Introduced in This PR

• 8.5.2 Construction Steps (Final Steps Added)

  • Sphinx packet construction
    • Assemble Final Packet
    • Transmit Packet

• 8.6 Sphinx Packet Handling

  • 8.6.1 Shared Preprocessing
    • Derives session key, validates replay tag and MAC, decrypts header/payload
  • 8.6.2 Node Role Determination
    • Inspects decrypted header prefix and padding to classify node as intermediary or exit
  • 8.6.3 Intermediary Processing
    • Parses next hop address and mean delay
    • Updates ephemeral key and routing fields
    • Samples actual forwarding delay and transmits packet
    • Erases all temporary state.
  • 8.6.4 Exit Processing
    • Verifies payload padding and extracts destination address
    • Parses and validates application-layer message
    • Hands off to Exit Layer along with origin protocol codec and destination address

Highlights

• Explicit role determination via zero-delay and padding inspection
• Fully decoupled construction and handling logic
• Forwarding delay behavior updated:
  • Sender selects per-hop mean delay
  • Mix node samples actual delay using pluggable distribution

[chaitanyaprem]

LGTM, i haven't reviewed the complete sphinx details as that would require me to understand it completely which i will do in due time.

[chaitanyaprem]

wondering if we should define these (e.g application message length) as constants somewhere up in the spec as var names and use them. If anything changes wrt packet size then it would be easier to update the spec.

[chaitanyaprem]

Since exit==destination is made default approach for Logos Messaging, should we modify this to indicate the same?
Another way would be to just indicate that there are 2 exit options and mention them in a separate section.

[jm-clius]

Looks reasonable at a high level. :) Approving to allow merging WIP.