Should `get_current_session()` be moved out of the function signature?

Background

get_current_session() appears in the function signature of many bslib functions, but it isn't exported, which may lead to confusion if users try to call this function directly.

IIUC, get_current_session() has three goals:

1. Find the current shiny session, but only if shiny is loaded
2. Require an active shiny session in certain functions
3. Allow the user to pass a reactive domain or suppress the shiny session when a reactive domain isn't required by passing NULL.

As far as I can tell, the active shiny session is required everywhere that get_current_session() is called, except for in bs_current_theme()

https://github.com/rstudio/bslib/blob/9c043a7b88c215b7fca57df4a37a0c601b8b296d/R/bs-current-theme.R#L31

With those goals in mind, it could be helpful to divide usage of get_current_session() into required and non-required active sessions.

Case: Active Session Required

When require_active = TRUE, then a session is required and NULL isn't a special value; if a user passes NULL, they'll likely get a downstream error. These two calls aren't exactly equivalent, but functionally they'll be the same from the user's perspective.

component <- function(session = get_current_session()) {
  # use session but not guaranteed to be valid?
}

component <- function(session = NULL) {
  session <- session %||% get_current_session()
}

We could also be even more explicit and split get_current_session() into two steps:

component <- function(session = NULL) {
  session <- session %||% get_current_session()
  assert_valid_session(session)
}

Case: Active Session Not Required

If the above make it possible to move get_current_session() out of the function signature of functions where it's used, then the last remaining function is bs_current_theme(). I believe this function is the only place in bslib where get_current_session() is called with require_active = FALSE.

https://github.com/rstudio/bslib/blob/9c043a7b88c215b7fca57df4a37a0c601b8b296d/R/bs-current-theme.R#L31-L38

Here's how bs_current_theme() is described in the documentation:

Calling this function at print/render time is important because it does different things based on the context in which it's called:

• If a reactive context is active, session$getCurrentTheme() is called (which is a reactive read).
• If no reactive context is active, shiny::getCurrentTheme() is called (which returns the current app's theme, if relevant).
• If shiny::getCurrentTheme() comes up empty, then bs_global_get() is called, which is relevant for rmarkdown::html_document(), and possibly other static rendering contexts.

From this description, it's not clear to me that bs_current_theme() needs to take a session argument. It seems like it'd be okay for the session to be found when called. Certainly internal use of bs_current_theme() is always without arguments; I also haven't found in-the-wild examples of the function being called with a session argument. In the worst edge-case, a very advanced user could wrap bs_current_theme() in shiny::withReactiveDomain() to choose a non-standard domain (but I'm still having a hard time imagining why).

One hypothetical I can imagine is that one might want to call bs_current_theme() while forcing it to avoid the reactive read of the theme. If that's important to support, perhaps it could be a specific argument rather than implied by the value of session?

Start with R/bs-current-theme.R and the other get_current_session() call sites, then compare how required and non-required sessions are handled in public signatures. Done means the session-handling design is settled and the affected callers and behavior are consistently updated.