Errors related to reaching the WiredTiger max session limit (here) can escape the storage layer through multiple interfaces. The so-far-observed consequences range from blocking serverStatus collection (SERVER-135249) to crashing the server entirely (SERVER-135242).

Having an LLM observe the edges, we can have this error escape through:

• RecoveryUnit methods that do lazy session attachment.
• The RecordStore interface
• The SortedDataInterface interface
• The KVEngine interface
• The WiredTigerBulkLoadCursr
• StatsCollectionPermit sessions
• More that aren't named here

This error is theoretically retryable, and hitting the limit is a potentially temporary condition that can go away. We need to reassess the story of when this error can escape the storage layer and whether retries should be part of session creation. Right now, I think it's unexpected for this error to leak out in the places it does, leading to upper layer code that (sometimes rightfully) doesn't have error handling. As part of this, we should improve our testing around running the server during an artificially constrained session limit, so that we we can avoid catastrophic scenarios like server crashes.