only lock row in pf purge thread when work to do

[jmg]

Summary

Only take a lock when we know that there is work to do.
When expiring states, we currently always take a lock, even when
the list is empty. We can check to see if the list is empty and
if it is, do not take a lock.

This is fine, as we'll check again in 10 seconds, and even if we
lost a race, it doesn't make sense for the state to immediately
time out.

On my Pine A64-LTS arm64 board, it dropped CPU usage of the pf
purge thread from 1.2% down to .28% CPU usage. This is on a system
where only kldload pf was done, and with out any rules loaded...
I'll be added additional testing from an active router...

This was inspired by the increase in cpu usage due to the recent
increase in hashsize.

[jmg]

note, if you apply the diff and check it w/ svn diff -x -wb, you'll see that the only change is the comment, the if, and the braces.

[jmg]

CPU usage calculated by taking the time pf purge ran and dividing it by the difference between now, and lstart:

ps -ax -o lstart,time,command | grep pf; date

Sun Sep 9 16:31:23 2018 0:30.95 [pf purge]
Sun Sep 9 19:33:53 2018 0:00.02 grep pf
Sun Sep 9 19:33:53 UTC 2018

30.95 / (30+2*60+3*60*60) == .283%

[jmg]

For reference, on an active pf firewall, before the patch, ~1.56% cpu core was used on the purge thread, after the patch, .427% cpu core. over a third less CPU. This is with the same 128k hash table size.