LPM Masking: Fix masking for fields with bitwidth non divisable by 8.

[dorakerman]

When prefix and/or bitwidth are not aligend to size of a byte, we must make sure the mask is applied correctly to all bits in field. Until now, the logic expected to find maximum of one byte that needs special masking, and that masking is relative to the "beginning" (MSB bits) of the bytes. This caused issues with fields that are smaller than a byte. Another issue, some fields and prefixed might need some bits of a the "first" and "last" byte in the prefix to be masked, for example: Field bitwidth = 20
Prefix length = 16
Mask should be = 0b11111111111111110000
Since we are representing in byte arrays, in bytes we get -> 00001111 11111111 11110000 (24 bits, 3 bytes)

Old implmentation disregarded the first 2 bytes and only masked the last byte (0b11110000).

Both issues are fixed in this commit, by this flow:

1. Utilizing prefix byte array, which is aligned to number of bytes needed to represent bitwidth in bytes.
2. Creating a mask for entire field, according to prefix length.
3. Applying it to all bits in prefix length.

Issue: #146

[jafingerhut]

If I understand correctly:

(1) When the P4Runtime API has an exact or ternary field with width W bits that is not a multiple of 8, the match value (and for ternary fields, the mask) are represented by the value being in the least significant W bits of a sequence of B=ceiling(W/8) bytes, i.e. the most significant (8*B-W) bits of the most significant byte must be 0.

(2) The same is true for a value of an lpm match field, too, regardless of the prefix length.

(3) Without the change in this PR, the p4runtime-shell seems to be expecting the value of such an lpm field to be aligned differently than that, and you want to change p4runtime-shell it so it more closely matches what the P4Runtime API messages require.

Please correct me if I'm have any of that wrong.

[jafingerhut]

(2) The same is true for a value of an lpm match field, too, regardless of the prefix length.

Out of curiosity, have you tested with the BMv2 software switch with a table that has an lpm field to confirm whether it expects this alignment of values for lpm fields when configuring it via P4Runtime API messages?

If not, would you be willing to try that out? I ask mainly because it would be nice to know that we are keeping all of these pieces consistent with each other for this scenario.