session::open_listen_port() might end up listening different ports for ipv4 and v6

[GoogleCodeExporter]

What steps will reproduce the problem?
1.I'm using deluged 1.3.5 with libtorrent 0.15.10.0 
2.Launch deluged and wait for a long time or reload config.
  In config, listening port range is 39091:39099
3.`netstat -tnpl | grep python` shows deluged is binding on different ports 
  for ipv4 and v6 0.0.0.0:39091 and :::39092

What is the expected output? What do you see instead?
Should bind to same port number for ipv4 and ipv6, since the bittorrent
protocol only report one port number to server. 
(Ref: http://www.bittorrent.org/beps/bep_0003.html)

What version of the product are you using? On what operating system?
I'm using deluged 1.3.5 with libtorrent 0.15.10.0 
On CentOS release 6.6 (Final)
RPM was from nux-dextop(http://li.nux.ro/repos.html)

Please provide any additional information below.

I tried to debug and searched through 0.15.10.0 source code.
I found this bug is possibly caused by open_listen_port() and 
setup_listener() in session_impl.cpp.

open_listen_port() is trying to bind to IPv4 port first, then IPv6 one,
using setup_listener(). 
If the ipv4 port is available, the ipv4 binding will succeed
(In my case 0.0.0.0:39091). 
Then setup_listener() will try to open the v6 port with same port number,
and if it found the v6 port occupied 
(In my case, possibly not yet released on reload), 
it will continue search for next available port and bind to it 
(:::39092)

At the end, session is binded to different IPv4 and IPv6 ports.

I also checked libtorrent 1.0.3, the bug seems still exist.

Original issue reported on code.google.com by dan.renyidong on 10 Dec 2014 at 10:37

[GoogleCodeExporter]

BTW, I checked listen_port() and it seems return port number of the first 
socket, which is the IPv4
one. This bug first occurred when I torrenting on a IPv6-only tracker. The 
tracker says my port is 
firewalled. I checked from external network with telnet and confirmed both IPv4 
and IPv6 port actually
works.

Possible fix: 1. confirm port number at the end of open_listen_port() 
              2. bind to IPv6 address with ipv6only=false

Original comment by dan.renyidong on 10 Dec 2014 at 10:44