fix join and unnest planning to ensure that duplicate join prefixes are not used

[clintropolis]

Description

This PR fixes a join query planning regression caused by #13902. After that change, this query will actually plan "correctly" but then later explode due to duplicate join prefix. The planner was selecting a join prefix only looking at the RowSignature of the left and right side datasources, but if those queries had any nested join prefixes, the query would later fail because the native prefix checker flattens the join to check prefixes (so losing the context of what is used directly in outside layers).

The solution Ive added is to just dig through the datasources to extract any existing prefixes and add that to the checked set when selecting new prefixes, to ensure the planner never picks duplicate prefixes even if it can't see them at the top level.

The added test plans and produces the same result as prior to #13902. Full disclaimer, I didn't actually work out the answer by hand to ensure that it was correct (the repro query was relayed to me), but at least it isn't different than before the change 😅 .

---

This PR has:

• been self-reviewed.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• been tested in a test Druid cluster.

[gianm]

The fix LGTM. It looks like a pre-existing bug with join planning: because we're only looking at the row signature when determining what rightPrefix to use, we might choose a prefix that was used for a join where no RHS columns were selected. (Like an inner-join-used-as-filter, as in your test case.)