Fix --bind-dev options for TCP streams. (#1099)

[chenshuo]

netdial() honors --bind-dev option but iperf_tcp_connect() doesn't,
as a result, only the control socket is bound to the device, but not
the data socket.

Instead of duplicaing code from netdial to iperf_tcp_connect(), this
fix extracts a common util function create_socket() from netdial() and
let iperf_tcp_connect() call create_socket() to create a socket with
optional bindings.

Tested on Raspberry Pi 3 with eth0 and wlan0.

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies:

• Issues fixed (if any): Bind to non-primary interface seems to not work #1099

• Brief description of code changes (suitable for use as a commit message):
  See above.

[dsahern]

The create_socket lines are really long and should be split across multiple lines, but the logic itself seems good and worked for me in my testing.

[bmah888]

Thanks for the PR! I've been playing with this. So far so good.

Recording my test setup for posterity:

Server: FreeBSD 13.0-RELEASE, vtnet0 10.0.2.7/24 (management), vtnet1 192.168.156.102/24
Client: Ubuntu 20.04, enp0s3 10.0.2.8/24 (management), enp0s8 192.168.56.108/24, enp0s9 192.168.56.109/24

On the server, do iperf3 --server.

On the client, do sudo tcpdump -n -i enp0s8 -Q out tcp port 5201 and sudo tcpdump -n -i enp0s9 -Q out tcp port 5201 to watch outbound packets.

On the client do iperf --client 192.168.56.102, iperf --client 192.168.56.102 --bind-dev enp0s8, and iperf --client 192.168.56.102 --bind-dev enp0s9.

With stock master code, binding to enp0s8 should be the same as not binding at all (all outbound traffic over enp0s8). Binding to enp0s9 gets some packets to go over enp0s9 but not all.

With the patch in this PR, binding to enp0s8 should still give the same results as not binding at all, but binding to enp0s9 should get all of the packets to go over enp0s9. (This seems to be what's happening, thus "so far so good".)

Now going to study the code changes. Thanks for the remarks in the PR about your approach to the problem, that tells me what to look for and how to interpret the diffs.

[bmah888]

This is great...it seems to work and I understand what you did. I especially like that the code is now shorter.