GwsQueryEngine evaluates incorrect join algorithm for joins involving SDF/SHP sources

[jng]

Sortability is a critical metric for optimum feature join performance.

Currently the GwsQueryEngine? does a check to see if select ordering is supported via the FDO provider capabilities. This check is not actually the final determinator for sortability, because sorting is also exposed via the FdoIExtendedSelect command, but this command only allows sorting on one property.

Therefore SDF/SHP sources, though they do not support standard select ordering, do support ordering via the FdoIExtendedSelect command, so the GwsQueryEngine? needs to check for this as well.

Attached is a patch that updates the sortability check. A given side of the join supports ordering if <it supports standard select ordering> --OR-- <it supports FdoIExtendedSelect command and only one property is being joined>

In my test cases, a full read from our joined test data (Sheboygan Parcels split into <ID/Geom> and <Attribute> halves, in SDF and SQLite flavours), where it previously used Nested Loops or Nested Loops sorted block (because the SDF side failed the sortability check, resulting in 20min execution time), it now uses sort merge (both sides pass the sortability check, resulting in 20s execution time).

[jng]

Patch to fix incorrect sortability checking

[jng]

Fixed with r6333

[jng]

This patch breaks the TestCase?_JoinFeaturesChainedInner1ToMany() test.

[jng]

Patch to refine property name checking for chained joins

[jng]

Supplemental fix submitted in r6348