Remove assumption that SCTP association ids will be unique

This is not the case under Solaris for one: successive
associations can receive the same association id as a result of peeloff,
the id only being unique for the controlling port, not for the listening
port as is the case under Linux for example. This made for many failures
in the diameter test suites, the traffic suite in particular.

Peeloff in diameter_sctp was introduced in 9a671bf0, before which the
assumption was fine since it was the listening process that owned all
associations. (Which obviously had other drawbacks.) Other remnants of
the pre-peeloff implementation have also been removed: that the listener
process might receive a message on a socket after peeloff for one.

Peeloff in gen_sctp became available in commit 067cfe79, after the
original implementation of diameter_sctp.

This is trace on the unpatched code showing id reuse under Solaris:

+ {trace_ts,<0.103.0>,call,
            {diameter_sctp,handle_info,
                           [{sctp,#Port<0.1625>,
                                  {127,0,0,1},
                                  35904,
                                  {[],{sctp_assoc_change,comm_up,0,32,32,1}}},
                            {listener,#Ref<0.0.1.948>,#Port<0.1625>,4,
                                      57384,
                                      {-4,61481},
                                      #Ref<0.0.8.12>,
                                      []}]},
            {1432,458752,612168}}
+ {trace_ts,<0.103.0>,call,
            {diameter_sctp,handle_info,
                           [{sctp,#Port<0.1625>,
                                  {127,0,0,1},
                                  35905,
                                  {[],{sctp_assoc_change,comm_up,0,32,32,1}}},
                            {listener,#Ref<0.0.1.948>,#Port<0.1625>,4,
                                      57384,
                                      {-3,61481},
                                      #Ref<0.0.8.12>,
                                      []}]},
            {1432,458752,613042}}

The result was this, when the second association was incorrectly
forwarded to the first association's controlling process:

** {function_clause,
       [{diameter_sctp,transition,
            [{peeloff,#Port<0.1635>,
                 {sctp,#Port<0.1625>,
                     {127,0,0,1},
                     35892,
                     {[],{sctp_assoc_change,comm_up,0,32,32,1}}},
                 []},
             {transport,<0.107.0>,accept,#Port<0.1634>,1,undefined,{32,32},0}],
            [{file,"transport/diameter_sctp.erl"},{line,561}]},
        {diameter_sctp,t,2,[{file,"transport/diameter_sctp.erl"},{line,549}]},
        {diameter_sctp,handle_info,2,
            [{file,"transport/diameter_sctp.erl"},{line,397}]},
        {gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,614}]},
        {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,680}]},
        {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,238}]}]}

0 files changed, 0 insertions, 0 deletions