Fix optional match key mask using XOR instead of shift

[gaetschwartz]

BfRtMatchActionKey::setValueOptional builds the mask for a valid optional key as (2 ^ field_size) - 1, treating ^ as exponentiation. In C++ this is bitwise XOR, so the mask is wrong for essentially every field size — e.g. an 8-bit field gets (2 XOR 8) - 1 = 9 (0b00001001) instead of 0xFF, and a 2-bit field underflows to an all-ones mask. As a result, optional match keys set through BF-RT match against incorrect bits instead of performing an exact match on the full field.

This computes the mask as (1ULL << field_size) - 1, falling back to UINT64_MAX for 64-bit fields since shifting by the full type width is undefined behavior.

[jafingerhut]

Looks like this was a bug, and a good fix, to me.

[jafingerhut]

@gaetschwartz The DCO check is failing for this PR. Please take a look at the page of the PR here #133 and find the "DCO" link in the section near the bottom under "Some checks were not successful". You can click on that link to get to a page with some suggestions for how to sign your commit for the PR.

If it is easier to create a new separate PR where you have done git commit -s with the -s option to sign the commit, that is fine, too. If you choose that option, please close this PR.