Implement new mechanism for tracking end-to-end connections across cable paths

[jeremystretch]

Proposed Changes

NetBox tracks end-to-end connections over pass-through ports. When a cable is saved, traces are done in both directions, and if a complete path has been established, the peer termination information is recorded at either of its endpoints.

This proposal seeks to devise and implement a new mechanism for tracking these end-to-end paths separately from the cable termination models. It may be desirable to introduce a new model (e.g. CablePath) dedicated to holding this information. Although more research is needed to identify the ideal solution, I've opened this issue now so that we can start referencing it as a blocker.

Justification

The association of end-to-end path data with specific device components and circuit terminations has proved problematic and inefficient (see the linked issues for examples).

[jeremystretch]

Although many of the details need to be refined, the high-level approach will be to model discrete cable paths individually for each connected object. For example, consider the following topology:

                1                           2
[Device 1] -----------+               +----------- [Device 2]
      Iface1          |               |          Iface2
                  FP1 |       3       | FP2
                  [Panel 1] ----- [Panel 2]
                  FP3 |   RP1   RP2   | FP4
      Iface3          |               |          Iface4
[Device 3] -----------+               +----------- [Device 4]
                4                           5

There are two end-to-end connections present, both via cable 3:

• Iface 1 <---> Iface 2
• Iface 3 <---> Iface 4

Currently, these connections are conveyed only on the four individual interfaces. A more robust approach would record each of the four unidirectional end-to-end connections individually, as:

1. (Iface1, Cable 1, FP1, RP1, Cable 3, RP2, FP2, Cable 2, Iface2)
2. (Iface2, Cable 2, FP2, RP2, Cable 3, RP1, FP1, Cable 1, Iface1)
3. (Iface3, Cable 4, FP3, RP1, Cable 3, RP2, FP4, Cable 5, Iface4)
4. (Iface4, Cable 5, FP4, RP2, Cable 3, RP1, FP3, Cable 4, Iface3)

This approach ensures that we can immediately query all potentially affected points along a path any time any single component within the path changes. For example, if cable 2 is deleted, we know immediately that paths 1 and 2 need to be updated.