Reduce the smux KeepAliveTimeout on the server from 10 to 2 minutes.

    // ReconnectTimeout is the time a Snowflake client will wait before collecting
    // more snowflakes.
    ReconnectTimeout = 10 * time.Second
    // SnowflakeTimeout is the time a Snowflake client will wait before determining that
    // a remote snowflake has been disconnected. If no new messages are sent or received
    // in this time period, the client will terminate the connection with the remote
    // peer and collect a new snowflake.
    SnowflakeTimeout = 20 * time.Second
    // DataChannelTimeout is how long the client will wait for the OnOpen callback
    // on a newly created DataChannel.
    DataChannelTimeout = 10 * time.Second

Just to note the worst case scenario here: ``` // ReconnectTimeout is the time a Snowflake client will wait before collecting // more snowflakes. ReconnectTimeout = 10 * time.Second // SnowflakeTimeout is the time a Snowflake client will wait before determining that // a remote snowflake has been disconnected. If no new messages are sent or received // in this time period, the client will terminate the connection with the remote // peer and collect a new snowflake. SnowflakeTimeout = 20 * time.Second // DataChannelTimeout is how long the client will wait for the OnOpen callback // on a newly created DataChannel. DataChannelTimeout = 10 * time.Second ``` If a client's session is interrupted and then they repeatedly get bad snowflakes (datachannel opens but does not move data), they'd cycle through at most `KeepAliveTimeout/(ReconnectTimeout + SnowflakeTimeout + epsilon)` where epsilon is the time it takes to reset the `ReconnectTimeout` timer or handle the `SnowflakeTimeout`. With the new `KeepAliveTimeout` that gives us 3 tries. Similarly, if a client has a tricky NAT topology and receives snowflakes that aren't compatible, they have at worst `KeepAliveTimeout/(ReconnectTimeout + DataChannelTimeout + epsilon)` tries that now figures out to 5 tries. These seem reasonable, but I think we should keep an eye on user reports and be prepared to bump this up a bit if needed. It's also possible we could tune the `SnowflakeTimeout` and `DataChannelTimeout` down. Also if a client is getting hit by that many `DataChannelTimeout`s we might have other adjustments to make.