SNOW-1869388 add memoization to to_selectable

[sfc-gh-aalam]

1. Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes SNOW-1869388

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
     • If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am adding new credentials
   • I am adding a new dependency
   • If this is a new feature/behavior, I'm adding the Local Testing parity changes.
   • I acknowledge that I have ensured my changes to be thread-safe. Follow the link for more information: Thread-safe Developer Guidelines

3. Please describe how your code solves the related issue.

   The process of adding WithQueryBlocks during repeated subquery elimination optimization takes place as follows:

• Identify repeated sub-query blocks
• Add a WithQueryBlock - a snowflake LogicalPlan node
• Create a SnowflakePlan out of the WithQueryBlock.

When parents for the WithQueryBlocks are updated, if the direct parent is a Selectable, we convert the SnowflakePlan into a Selectable using to_selectable. In case the WithQueryBlock has multiple parents, which by construction will always be true, a new Selectable object is created for each parent. See example below where new selectable nodes are highlighted in gray:

When large query block is applied on this plan, and the WithQueryBlock is chosen at eligible, since all these blocks have same statistics, they will all be eligible together and possible be materialized we create redundant materializations. The correct construction for such a case should look like the plan shown below:

[sfc-gh-helmeleegy]

Can we have a more descriptive name to this lock -- similar to _plan_lock below?

[sfc-gh-aalam]

this lock is actually part of Session object and used as a general purpose lock for serialization:

snowpark-python/src/snowflake/snowpark/session.py

Line 644 in ba31301

self._lock = create_rlock(self._conn._thread_safe_session_enabled)

[sfc-gh-helmeleegy]

Looks good, thanks!

[sfc-gh-yzou]

we probably should remember the original logical plan id instead of the resolved plan id, because the different snowflake plan might be created for the same orignal plan node

[sfc-gh-jdu]

Yea it's true

[sfc-gh-yzou]

in fact, it should always be true in query generator instead of propogating from the snowlfake plan

[sfc-gh-yzou]

why do we need a lock here, but not at other place in query_generator?

[sfc-gh-aalam]

We don't need it. query generator is not shared between threads so we should be good. That's why it is not added in other places.