Add Lookup#resolveGroup method and make Lookup#resolve depricated

[sopel39]

In the future, equivalence based memo would
store multiple plan nodes per group. Therefore
resolve() that returns singleton should be unused.

This is part of ongoing effort to introduce equivalence based memo and exploratory optimizer: #7169
It is natural step after Support simple pattern matching with captures that makes rule interface compatible with equivalence based memo.

FYI @martint @kokosing

[sopel39]

@martint your opinion would be appreciated

[kokosing]

I would refrain with this for a while as I have some doubts if the fact that memo holds multiple nodes per group should be exposed to rules.

Why not to work on traits? This would be helpful even with current memo and rules implementation. We could port QueryCardinalityUtil or DistinctOutputQueryUtil.

[kokosing]

As I said, lets wait a bit with this.

[sopel39]

I would refrain with this for a while as I have some doubts if the fact that memo holds multiple nodes per group should be exposed to rules.

That is the intention of this PR. We already rely on singleton Lookup#resolve a lot and since we have pattern matching we should discourage users from using resolve() by exposing the fact that there might be group of nodes underneath (it is counter-intuitive that GroupReference resolves to just one node). Instead of dropping the bomb and removing Lookup#resolve (which will take some time to do since we need to port rules that depend on it) it is better to make it compatible with equivalence memo and slowly port rules while not adding new rules that use singleton Lookup#resolve.

After this PR lands it opens multiple parallel/independent tasks:

• model traits so that we can port rules that use singleton Lookup#resolve
  • incorporate traits in iterative optimizer
  • port rules when traits are modeled/implemented
• implement support for groups in pattern matcher
• start working on equivalence memo and exploratory optimizer (we want it to implement Memo interface)

I think this PR is next logical step in order to continue optimizer since we slowly want to divert from Lookup#resolve

[kokosing]

Instead of changing this method, I would deprecate it and add a new method resolveGroup which would be used to implement this method.

[sopel39]

applied comment

[kokosing]

minor comments

[kokosing]

please update javadoc

[kokosing]

I would use Collections.singletonList() instead of ImmutableList.of with single argument. But up to you.

[sopel39]

ImmutableList.of() plays better with ImmutableList.copyOf.