Fix how MAC addresses are handled by the rules parser

[lel-amri]

Fixes #2175.

It wasn't ignoring separator characters such as the colon and hyphen. The rules compiler automatically add a colon to separate bytes, which is not compatible with how they are parsed.

---

This is currently a draft, as I'm not particularly versed in C++, and I think I couldn't fit well with the style used at Zerotier Inc.

[laduke]

Thanks for doing this. We will try to test it soon. Do you have a quick sample ruleset that shows the problem?

[lel-amri]

I think a direct and minimal test would be the following ruleset:

drop macsrc AA:AA:AA:AA:AA;
accept;

which compiles to the following JSON:

{
 "rules": [
  {
   "type": "MATCH_MAC_SOURCE",
   "not": false,
   "or": false,
   "mac": "aa:aa:aa:aa:aa"
  },
  {
   "type": "ACTION_DROP"
  },
  {
   "type": "ACTION_ACCEPT"
  }
 ],
 "capabilities": [],
 "tags": []
}

Because of the bug, host AA:AA:AA:AA:AA is not filtered.

The following JSON should work though:

{
 "rules": [
  {
   "type": "MATCH_MAC_SOURCE",
   "not": false,
   "or": false,
   "mac": "aaaaaaaaaa"
  },
  {
   "type": "ACTION_DROP"
  },
  {
   "type": "ACTION_ACCEPT"
  }
 ],
 "capabilities": [],
 "tags": []
}

[joseph-henry]

Unfortunately I don't think I can merge this because the result of cleanMac (which is void) was being passed to the constructor of std::string which cannot work. I've pulled your changes from your fork and made a new branch with additional fixes. We still need to do a proper end-to-end test.

Closing this PR.

[lel-amri]

Thanks for working on this :)
Indeed I overlooked that, and I did not run the code.
Also, maybe doing the operation in-place is not a good design, I'm not sure.

[joseph-henry]

Thanks for the effort and we can still work on merging in your change with the extra fix on the other branch. Feel free to test it.