Snowflake client's global session manager is tied to melted SnowflakeCollector
There was a bug introduced by our solution to #21314 (closed). We moved the broker poll loop inside the SOCKS handler, which means that each SOCKS connection effectively has their own pool of snowflakes (i.e., their own SnowflakeCollector). However, the session manager was kept global (shared by all connections). The session manager defines the dialContext for RedialPacketConn and is tied to the SnowflakeCollector it was created with.
The problem with this showed up most clearly in #40018 (closed), where mobile applications using Snowflake as a library are stopping and restarting Snowflake, but will happen in any scenario where the first SnowflakeCollector is melted, but a new SOCKS connection is created.