pfroute: extract netmasks correctly on Darwin/NetBSD

[evverx]

by skipping the 2-byte sin_port field and switching to the network byte order when RTA_NETMASKs are parsed.

Apart from the unit tests it was tested on NetBSD (32 and 64 bit) and Darwin and also cross-checked with netstat and route.

It's a follow-up to 528626a.

AI-Assisted: no

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.51%. Comparing base (5e13d41) to head (0e22d18).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #5074   +/-   ##
=======================================
  Coverage   80.50%   80.51%           
=======================================
  Files         390      390           
  Lines       96785    96785           
=======================================
+ Hits        77920    77923    +3     
+ Misses      18865    18862    -3     

Files with missing lines	Coverage Δ
scapy/arch/bpf/pfroute.py	92.64% <100.00%> (ø)

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[evverx]

This is a cool test in the sense that it helped me to notice the wrong byte order. The corresponding sockaddrs are

[<sockaddr  sa_len=16 sa_family=AF_INET sin_port=0 sin_addr=172.23.192.0 sin_zero=b'' |>,
 <sockaddr  sa_len=18 sa_family=AF_LINK sdl_index=1 sdl_type=6 sdl_nlen=0 sdl_alen=0 sdl_slen=0 sdl_iface=b'' sdl_addr=b'' sdl_sel=b'' sdl_data=00000000000000000000 |>,
 <sockaddr  sa_len=7 sa_family=255 sa_data=fffffffff0 |>,
 <sockaddr  sa_len=18 sa_family=AF_LINK sdl_index=1 sdl_type=6 sdl_nlen=4 sdl_alen=6 sdl_slen=0 sdl_iface=b'hvn0' sdl_addr=00:15:5d:00:65:0a sdl_sel=b'' sdl_data= |>,
 <sockaddr  sa_len=16 sa_family=AF_INET sin_port=0 sin_addr=172.23.207.191 sin_zero=b'' |>]

and looking at

>>>  pfmsghdrs(b).msgs[3].addrs[2].sa_data[2:]
b'\xff\xff\xf0'

it's kind of obvious that the netmask should be /20 (255.255.240.0) but it produced 240.255.255.0 instead. I had /4, /8,/24 and /32 locally and it worked regardless of the order but /20 is different.