Consider allowing branches in the graph to rejoin other branches in the graph

[RoganDawes]

This may allow for more understandable/configurable graphs when protocols change for whatever reason.

For example, we may have a graph that implements an HTTP pipeline, but we also support WebSockets. When the WebSockets upgrade happens, the graph needs to change quite dramatically, removing all of the HTTP protocol decoders/encoders, etc. This is currently done programmatically, but it means that the new graph is no longer shown in the visual representation.

If we allowed branches to rejoin an existing connection, it would allow us to include new Protocol Decoders, ScriptHandler's, etc on the upgrade branch.

The problem with this from a conceptual perspective is that ideally we want the WebSocketUpgradeHandler to branch from the graph BEFORE the HTTP decoders/encoders on the server side, and rejoin the branch below the decoders on the client side, so that we can simply remove all handlers between where the branches diverge and rejoin. However, the WebSocketUpgradeHandler also wants to work with decoded HTTP request and response objects, not raw bytes, which means it needs to be placed AFTER the decoders/encoders have done their work.

Currently the upgrade handlers just walk the pipelines backwards looking for the http codecs and object aggregators, and this may just have to continue.

[RoganDawes]

This could be achieved by making branch/decision nodes more "GraphAware", but also differentiating between connections created in Inbound vs Outbound directions, so that the GraphAware nodes know in which direction to retrieve more nodes.