Improve stability and visibility of session-concurrency checks

[achimnol]

Currently, we are implementing per-user limits of the maximum number of concurrently running sessions using counters: "compute" sessions and "SFTP" sessions. They are distinguished using a computed property is_private, which bases on the kernel_role attribute of sessions.

• Prerequisite: refactor: Merge kernels.role into sessions.session_type #1587
  • Related: Exclude SYSTEM sessions from resource allocation while keeping per-container resource limits #1672
• DIRECT_ACCESS sessions: overriden by Storage resource group #2791.
• Extend existing max_session_concurrency_limit to a mapping of per-session-type limits.
• Fix potential mismatch of the concurrency limit tracker in Redis and the actual database states.
  • There is a report that Recalculate resource usage is required to fix up the mismatch in production.
  • Could we just count the database rows when required by optimizing database indexes?
• Update webui and control-panel to allow admins to configure the per-session-type concurrency limits in GUI.

[achimnol]

During work on #2848 and review for #1587, I just found that the check_concurrency predicate does NOT satisfy the reentrancy assumption, meaning that it increments the concurrency-used counts whenever the scheduling is retried due to failure of other predicates.

This bug has been kind-of hidden because we have relied on the full recalculation upon session termination.