CBL-5170: Support Inner Unnest Query in SQL++

[jianminzhao]

Introduced a mew keyword, UNNEST.

Also, moved definition of reserved words from n1ql_parser_internal.h to n1ql.leg, to keep the list from out-of-sync from the LEG grammar, because the definitions in leg file will be compiled by LEG. We found, in n1ql_parser_internal.h, that MISSING is duplicaed, NATURAL and USING are not used, and EXISTS and SOME are missing in the list of kReservedWords

[cbl-bot]

Code Coverage Results:

Type	Percentage
branches	67.68
functions	79.07
instantiations	35.12
lines	79.03
regions	74.91

[pasin]

Will this cause any performance impact to the parser?

[jianminzhao]

It should be performant because, I think, LEG compiler will create a regex state machine. In any case, the performance impact will be minuscule, unless dealing with large n1ql file with a lot of identifiers.

[borrrden]

We are going to need to discuss how to handle this because it will break a potential query like the following:

SELECT * FROM unnest where unnest is the name of the collection

Both the act of making it a reserved word, and using it as a keyword is a change that is probably not suitable for a patch release. That being said, we should add in any words that we think may be used in the future to reserved words ASAP the way that server does (in fact we might just copy their list)

[jianminzhao]

If this is a constraint, I may be able to get away without having it a reserved word. That means, work harder making grammar more stringent so that unnest means unnest only in second appearance of "unnest" of "from x unnest unnest". but this is not very appealing.

[pasin]

Per the discussion that we will make unnest a reserved keyword and the input from @jianminzhao that the change to move the reserved keyword check to the parser itself should have minior performance impact, I'm approving this PR.

[jianminzhao]

I reviewed the handling of reserved words in this PR, motivated by the sensitivity of new reserved words to API compatibility.
I tried to ensure that, with the refactoring, I don't change the set of reserved words except for the new one, UNNEST. During the effort, I found 3 words that the grammar apparently takes as keywords but not in the list of reservedWords in n1ql_parser_internal.hh, which I removed in this PR.
The upshot is, ALL, EXISTS, and SOME, happens to be parsed in intended grammatical positions. Because they are not keywords, I can have
SELECT some.exists AS all FROM _ AS some
parsed successfully. If they were reserved words, the above query won't parse.
My intent is to keep the above behavior.

[borrrden]

That reasoning is correct. I believe in 4.0 we should make all of them reserved to get more parity. Though I thought we had agreed that UNNEST would behave as these three exceptions do now in order to minimize the potential breakage, and then make it an actual reserved word in 4.0.