Fix Session ID Allocation

[msandstedt]

Secure session ID allocation currently suffers the following problems:

• fragmentation has worst case behavior where there may be as few as
  2 outstanding sessions, but the allocator will become full
• there is no formal coupling to the session manager object, but
  yet there can only be one allocator per session manager; the
  current solution is for the allocator to share static state
• IDs are proposed to the session manager, which means the session
  manager can only prevent collisions by failing on session creation
  or by evicting sessions; it currently does the latter
• session ID allocation is manual, so leaks are likely

This commit solves these problems by moving ID allocation into the
session manager and by leveraging the session table itself as the
source of truth for available IDs. Whereas the old flow was:

• allocate session ID
• initiate PASE or CASE
• (on success) allocate session table entry

The new flow is:

• allocate session table entry with non-colliding ID
• initiate PASE or CASE
• activate the session in the table

Allocation uses a next-session-ID clue, which is 1 more than the most
recent allocation, and also searches the session table to make sure
a non-colliding value is returned. Allocation time complexity is
O(kMaxSessionCount^2/64) in the current implementation.

Lifecycle of the pending session table entries also leverages the
SessionHolder object to alleviate our need to manually free resources.

Fixes: #7835, #12821

Testing:

• Added an allocation test to TestSessionManager
• All other code paths are heavily integrated into existing tests
• All existing unit tests pass

[mrjerryjohns]

All the whole, a really great PR, thank you for clean-ing this up! The ownership model is much better with the fact that you're allocating a session now from SessionManager, and not just a SessionID.

[kghost]

Pretty solid change for session ID allocation implementation.

While reading the code, I feel there are a few improvements we can do in the future:

1. PairingSession as a base class for PASE and CASE pairing, almost provides nothing in common for these 2 cases. We can leave PairingSession an almost empty virtual interface and push its fields down into PASESessoin and CASESession classes.
2. Every API of PairingSession takes an argument of SessionManager, since it is highly coupled with the SessionManager, we can add a ref to SessionManager into its member.