Reassess cookie_mask default value and/or mandatory value

[viniarck]

Currently, both flow_manager and pyof use 0 a default value for cookie_mask, and since at hte moment, cookie_mask is optional, if a user only sets cookie as a numeric value, then it would result in 0, which could be undesirable, @italovalcy has caught this situation recently.

We need to decide if we'll use a neutral default value all 1s or always require cookie_mask if cookie is set, and it's worth comparing this behavior with OvS as well to be sure since the OF spec doesn't specify much about this point.

[viniarck]

@italovalcy, I've had the chance to also compare with OvS 2.16.1, and they require cookie_mask as mandatory, and in their example they suggest to use all 1s, although all 1s isn't a default value that they use:

❯ sudo ovs-ofctl del-flows s1 "in_port=1,cookie=0x1000" -O OpenFlow13
ovs-ofctl: cannot set cookie (to match on a cookie, specify a mask, e.g. cookie=0x1000/-1)

❯ sudo ovs-ofctl del-flows s1 "in_port=1,cookie=0x1000" --strict -O OpenFlow13
ovs-ofctl: cannot set cookie (to match on a cookie, specify a mask, e.g. cookie=0x1000/-1)

So, that is also another confirmation that validation is a crucial part to avoid ambiguity.

Trying to use all 1s as a default for cookie_mask could lead to ambiguity since the user might actually mean cookie 0 and could expect cookie_mask 0 to match any cookie and not only cookie 0 specifically, so this can lead to surprises (and since the spec doesn't say which one is the default it will always give margin for interpretation whether cookie_mask should be all 0s or all 1s by default), and on pyof to try to account for unset values it would require to use None as default values and set the integer value based on whether it has been set or not (and then the same problem would be deferred to there to define a base case). It looks like validation with a mandatory value while maintaining as it is the safest and less surprising route. Let me know if you agree or if you see this differently.

[viniarck]

Linking issue #43 here since it's related to validation