fix(api-gateway): make sure DAP works with sql pushdown

[bsod90]

fixes an issue when processing queries with member expressions

Check List

• Tests has been run in packages where changes made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Issue Reference this PR resolves

[For example #12]

Description of Changes Made (if issue reference is not provided)

[Description goes here]

[mcheshkov]

I've not yet checked yet what can applyRowLevelSecurity introduce

But parseMemberExpressionsInQuery is not enough anyway.
There's three states of member expressions:

1. MemberExpression
   Object with expression method, that takes cubes as symbols and returns SQL

2. ParsedMemberExpression
   Object with expression as array of strings. Essentially JSON-compatible way of storing MemberExpression

3. Just a string with JSON-serialzed ParsedMemberExpression.

Schema compiler expects only MemberExpression.
parseMemberExpressionsInQuery turns strings in proper places in query to ParsedMemberExpression.
evalMemberExpressionsInQuery turns ParsedMemberExpression to MemberExpression in those places.

So, depending on what applyRowLevelSecurity can add either only evalMemberExpressionsInQuery, or both of parseMemberExpressionsInQuery + evalMemberExpressionsInQuery are necessary.

[mcheshkov]

expression: () => '1 = 0',
That's MemberExpression, with expression as method, returning SQL. For this case no need to add any additional calls after applyRowLevelSecurity

String member expression would look like something this: query.segments.push('{"cubeName":"foo","expr":"1=0"}');
This would require to add both calls to parse and eval

[bsod90]

Sorry, I've removed all my previous comments and just added the eval. Looks like it should be fine now

[mcheshkov]

Please, add comment about why early/second call is necessary. I'll probably forget about this whole issue next week 😅