WIP: Support for layered transport state

[yadij]

Stage 2 of the layered transaction model initiated with MasterXaction class creation.

This stage implements the actual layering mechanism for transport protocol changes on a socket. Initial layers TCP, TLS, and PROXY are labeled for client initiated sockets. Squid initiated sockets are not labeled.

[yadij]

By definition, master transaction cannot have sub-master-transactions. While there are certainly many transactions and many processing layers related to a single master transaction, each of them is not a master transaction. That all-encompassing nature is the whole idea behind the master transaction concept! Squid code goes against that idea in a couple of places, but all those violations can/should be fixed and should be ignored as far as high-level design decisions are concerened.

For example, adding TLS or PROXY protocol message handling to an accepted TCP connection does not create a new master transaction. We continue to handle the same master transaction, just adding processing layers.

After reading the PR description, I am not sure where this PR is heading or what it is trying to accomplish. However, the above problem seems to be significant enough to warrant raising a red flag at the current WIP stage.

This is the model I have been designing since the very beginning. You may recall I did not choose the name "master" for the class initially - the ambiguity you refer to is why I perfer not having a class named "master" transaction at all.

With this architecture the MXA instance which Server points to is the primary source of details for the transaction that Server is performing. txParent will be some previous (aka "wrapping") protocol from an earlier transaction which we might need state data from. The current xaction protocol might have a way to "end" and revert to txParent activity on the socket - but most protocols will not so txParent is essentially just historic data. txChild is there so we do not require a 1:1 parent-child relationship ( it could be a childA->parent->childB situation).

For example, with SSL-Bump the txParent will be the "HTTP" layer with all the details (ie auth credentials, original URI) from CONNECT which might be needed by ACLs and security checks. But the "master" is still the active MXA for the "TLS layer.

Long-term we should have the fd_table details are in the MXA and code that can handle arbitrary amounts and types of protocol switching on a port.

This stage 2 scope is getting MXA from TcpAcceptor to be usable by Server class hierarchy. The MXA which were being spawned as entirely separate objects are now connected to it by the spawner. Polishing up this stage will be making Server classes use their xaction for state access+storage - eg what the PROXY handling code now does.