Use less restrictive column access checks when using transform and cardinality functions

[pranjalssh]

Commit 1:

When doing subfield access checks in sql like transform(a, col -> col.x).

We previously checked for permission of column a.
After this PR, we will check for permission of column a.x.

To do this, we need to do 2 things:

1. Parse lambda functions, and map lambda argument col to table column a for access checks
2. Don't do access check for first argument to transform, a

This PR does both for them.

These cases are hardcoded just for the transform function. Adding other functions to these checks is easier, as demonstrated in commit 2, where we skip the check completely for cardinality function.

== RELEASE NOTES ==

General Changes
* Use less restrictive column access checks when using `transform` and `cardinality` functions

[amitkdutta]

[ RUN ] TaskManagerTest.outOfQueryUserMemory
*** Aborted at 1671785665 (Unix time, try 'date -d @1671785665') ***
*** Signal 11 (SIGSEGV) (0x18) received by PID 3865 (pthread TID 0x7f5d3e020780) (linux TID 3865) (code: address not mapped to object), stack trace: ***
(error retrieving stack trace)

This is fixed in #18842

[rschlussel]

can you add access control tests too (create a test access control with some column restrictions and confirm you don't get an exception if accessing allowed subfields or using cardinality function.)

[rschlussel]

why? why not use recursion to go into all of them?

[pranjalssh]

This part is moved from ExpressionAnalyzer as well. This function is called once for each dereference, when multiple dereferences are nested. So, we have this check that only looks at the dereference chain once.

[rschlussel]

i think all the different cases here are a bit confusing. Needs some comments, but I think it would be clearer if written as a visitor instead of a while loop with each case determining whether to continue the loop. It would also be easy to introduce an infinite loop in this logic(continue gets called without the child nod getting updated to something that would break the loop eventually)

[pranjalssh]

I don't want to modify this logic in this PR. This is an existing logic moved from ExpressionAnalyzer to here, which is already tested. I can put up a todo to refactor it.

[pranjalssh]

Added comments

[rschlussel]

got it. I guess it's okay since the code already existed. would be good to refactor though as a follow up.