pf: Access r->rpool.cur->kif under mutex protection

[vegeta_tuxpowered.net]

Summary

pf_route() sends traffic to a specified next hop over a specific interface. The next hop is obtained in pf_map_addr() but the interface is obtained directly via r->rpool.cur->kif` outside of the lock held in pf_map_addr() in multiple places around pf. The chosen interface is not stored in source node.

Move the interface selection into pf_map_addr(), have the function return it together with the chosen IP address and ensure it's stored in struct pf_ksrc_node, store it in the source node and use the stored value when needed.

Sponsored by: InnoGames GmbH

Test Plan

I've ran the tests from /usr/tests/sys/netpfil/pf, all pass. The issue was found when playing with this rule:

pass in quick on n_test_h_rtr \
    route-to { ( n_srv_h_rtr <serversA> ) , ( nonexistent <serversB> ) } round-robin sticky-address \
    proto tcp \
    to <lb_pool> port 80 \
    tag maciora

The client has multiple IP addresses it can use as source. It first makes a connection from source1 which lands on serverA2@n_srv_h_rtr (this thing always starts at 2 for whatever reason, that is not important for this bug). Then the next connection is made from source2 and lands on serverA3@n_srv_h_rtr. The next connection is made from source3 and lands on serverB1@nonexistent. This updates r->rpool.cur which is now used for all new connections, even ones matching existing source nodes. A new connection from the client from source1 fails because it gets mapped to serverA2@nonexistent, as only the IP address is stored in the source node.