sctp_status: fix usage of max_stream parameter

Hangbin reported the following error:

remote:addr=127.0.0.1, port=distinct, family=2
local:addr=127.0.0.1, port=distinct32, family=2

Starting tests...
         socket(SOCK_STREAM, IPPROTO_SCTP)  ->  sk=3
         bind(sk=3, [a:127.0.0.1,p:distinct32])  --  attempt 1/10
         connect(sk=3)
Client: Sending packets.(1/10)
         sendmsg(sk=3, assoc=0) 17768 bytes.
           SNDRCV(stream=1 flags=0x1 ppid=846930886)
         sendmsg(sk=3, assoc=0) 6250 bytes.
           SNDRCV(stream=2 flags=0x1 ppid=1714636915)
         sendmsg(sk=3, assoc=0) 23634 bytes.
           SNDRCV(stream=3 flags=0x1 ppid=424238335)
         sendmsg(sk=3, assoc=0) 5195 bytes.
           SNDRCV(stream=4 flags=0x1 ppid=1649760492)
         sendmsg(sk=3, assoc=0) 7978 bytes.
           SNDRCV(stream=5 flags=0x1 ppid=1189641421)
         sendmsg(sk=3, assoc=0) 22715 bytes.
           SNDRCV(stream=6 flags=0x1 ppid=1350490027)
         sendmsg(sk=3, assoc=0) 16883 bytes.
           SNDRCV(stream=7 flags=0x1 ppid=1102520059)
         sendmsg(sk=3, assoc=0) 10724 bytes.
           SNDRCV(stream=8 flags=0x1 ppid=1967513926)
         sendmsg(sk=3, assoc=0)  125 bytes.
           SNDRCV(stream=9 flags=0x1 ppid=1540383426)
         sendmsg(sk=3, assoc=0) 2133 bytes.
           SNDRCV(stream=10 flags=0x1 ppid=1303455736)

                 *** sendmsg: Invalid argument ***

The problem is that we use stream numbers that are larger than the
default ones. So in the case the user requests a particular maximum
stream number, tell that to the kernel so that we won't end up with
an -EINVAL when sending.

Reported-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>