Another attempt to address pion#134, see an earlier attempt in pion#222. pion#222
introduces the DeniedPeerRange stanza into the ServerConfig to
implement peer address blacklisting. This approach has a couple of
issues: (1) it implements only peer blacklists, but does not allow
whiletelisting or filtering based on DNS, etc.;(2) it handles only the
ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.

Another attempt to address pion#134, see an earlier attempt in
pion#222. pion#222 introduces the DeniedPeerRange stanza into the
ServerConfig to implement peer address blacklisting. This approach has
a couple of issues: (1) it implements only peer blacklists, but does
not allow whiletelisting or filtering based on DNS, etc.;(2) it handles
only the ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.

Another attempt to address #134, see an earlier attempt in
#222. #222 introduces the DeniedPeerRange stanza into the
ServerConfig to implement peer address blacklisting. This approach has
a couple of issues: (1) it implements only peer blacklists, but does
not allow whiletelisting or filtering based on DNS, etc.;(2) it handles
only the ChannelBindRequest codepath, but leaves the CreatePermission
codepath (https://datatracker.ietf.org/doc/html/rfc8656#section-3.4)
open; and it introduces a new package dependency on "inet.af/netaddr".

This patch takes a different approach: it allows the user to specify a
PermissionHandler callback for each PacketConnConfig/ListenerConfig in
the ServerConfig. Whenever a permission is about to be created via the
associated PacketConn/Listener (either via a ChannelBindRequest or a
CreatePermission), the PermissionHandler is called with the requested
peer address and it can decide whether to accommodate the permission
request (return boolean true) or deny it (return false). In the latter
case, a "permission request administratively prohibited" error is
returned to the client.

Also added tests and an example.