dispatcher: Add ping_sock as a partition parameter

[NormB]

Summary

This PR enhances the dispatcher module. It adds 'ping_sock' to the partition parameter.
The 'ping_sock' can be used to specify, per partition which interface pings / probes are sent from.

Details

The 'ping_sock' parameter can be used when the OpenSIPS server has multiple interfaces. For example,
when operating as an SBC, the server may have a public interface to communicate with carriers and a private
interface to communicate with proxies. In this scenario partition tables for carriers can have pings / probes use the public
interface and proxies can use the private interface.

Solution

The dispatcher module currently uses a global "probing_sock" interface to ping / probe destinations. There is no ability to define which interface is to be used to ping / probe a particular set of destinations. This works ok when there is just one "pool" of destinations all more or less handling one function such as "carriers". When multiple destination classes exist, and are defined in multiple partitions the 'ping_sock' offers the ability to have each partition ping / probe destinations from a different interface.

The dispatcher tables have a 'sock' column, however this is not used for pinging / probing operations. A future enhancement may be for this 'sock' column to be used for pinging / probing also.

Compatibility

Since this is a new parameter there are no compatibility problems with existing configurations. If the parameter is not specified, the existing flow will continue to be used.

Closing issues

[liviuchircu]

LGTM, @NormB! My only comment is regarding naming consistency, because I see two notions being used for the same thing throughout the module: "pinging" and "probing". However, your PR is consistent with the other partition params, so your choice of ping_sock seems to be a good one!

[NormB]

LGTM, @NormB! My only comment is regarding naming consistency, because I see two notions being used for the same thing throughout the module: "pinging" and "probing". However, your PR is consistent with the other partition params, so your choice of ping_sock seems to be a good one!

Completely agree with your comment. I was trying to find a reasonable trade-off between the parameter names and the variables names in the code. If probe_sock was used as a partition parameter, it would likely cause confusion with the module parameter for users as well as confusion for developers maintaining the module.

[liviuchircu]

Build is passing now, let's merge it!