Fix slice generation for table keys in P4_14->16 conversion

[ChrisDodd]

This fixes the P4_14->P4_16 converted to not generate completely invalid code for this case, but it still causes problems in the typechecker when the mask is disjoint.

Trying to split such disjoint masks into multiple key elements would be possible, but its not clear how the name/API should be managed for the result. Easiest would be if P4_16 supported mask expressions in keys like P4_14 -- see issue #404

[mihaibudiu]

The key can be expressed as a concatenation of slices.
Alternatively, the key could be a slice from the first 1 to the last 1 bit.
The actual representation depends on how the information is used in the back-end and in the control-plane API. Until we have a specification on how that is done we cannot really write this code.

[ChrisDodd]

I've pushed a further change that allows the masked keys to get through the frontend (not issing a type error, and adding a policy that allows them), and generate the json for the bmv2 backend which makes this test case work.

The p14_to_16 translation fails because on reparsing the dumped p4_16 code, it chokes on the mask in the key. Adding support for that would be a trivial parser addition.

[mihaibudiu]

We have two solutions:

• we change the P4-16 spec and define masks for keys; then we can parse this, and we add support everywhere for it. In particular, the typechecker has to check that the mask and the key have the same type too.
• we don't change the spec, but we support P4-14 on BMv2; for this purpose the solution is to use an annotation called @Mask on the key to carry the mask through the front-end. The back-end will have to do the typechecking during code generation. This should be relatively easy since the mask is supposed to be a constant anyway.

Neither of these is too much work. I would propose using the second solution currently - at least until the spec is modified. Your PR would be easy to fix to use the second solution, and it should not need to touch any of the intermediate passes.

[ChrisDodd]

Actually, now I think about it more, since P4_16 allow arbitrary expressions in tables keys, we don't really need masks as such -- just use a & (bitwise and) expression with a constant. The result will be an expression with the ignored bits zeroed out, which is more or less what BMV2 wants.

[mihaibudiu]

You are right.
If the control-plane does not need to know the mask this is probably all you need.
There is still the generation of the @name annotation for the key - which is done in a latter pass.
You may need to do it right when you create the key.

[ChrisDodd]

So I've updated this change to use IR::BAnd expressions when converting mask keys that can't be converted into simple slices. I've also extended tableKeyNames to generate a name for the BAnd when one operand is a constant, so this now all works correctly.