Support use of partial session ID for routing purposes

QFJ-272/1.3.1 added several fields to SessionID (SenderSubID, TargetSubID, SenderLocationID). These fields will be populated in MessageUtils.getReverseSessionID(...) if they are set in the Login message. They then form part of the session look-up in AbstractSocketAcceptor.StaticAcceptorSessionProvider.

In 1.2.1 and below, MessageUtils.getReverseSessionID included only the comp IDs, not the sub-IDs and SenderLocationID.

This breaks us in two ways. One is that we have been configuring our sessions by the comp IDs, which works well with the 1.2.1 code but mismatches with the 1.3.1+ code even if both sides get all their IDs right.

The other, and more important, is that several of our customer gateways will vary the SenderSubID and/or TargetSubID. For example, the FIX spec describes SenderSubID as being useful to distinguish between traders, and that messages not intended for a particular trader may optionally be flagged as ADMIN. It seems to me that the changes in QFJ-272 have resulted in a restrictions/obstacles beyond what was really intended by the spec, and certainly beyond what our customers will handle.

Fortunately there is a mechanism to provide your own AcceptorSessionProvider, which can be used to work around this issue. That said, the default behaviour is not ideal. Attached is a patch to replace StaticAcceptorSessionProvider with a new class, DefaultAcceptorProvider, which first tries a "strict" 1.3.1-style lookup, and if it fails, tries a 1.2.1-style lookup based on the Comp IDs only.

If the maintainers have an objection to the patch, I would suggest at the least that something like DefaultAcceptorProvider (plus instructions) be included in the distribution for those who cannot use StaticAcceptorSessionProvider.