Add WebSocket handler for WebUI database sessions

[gabrielcorado]

Part of #44956 (RFD 0181)

This PR adds a new WebSocket that the WebUI will use to start database sessions. Those sessions will rely on protocol-specific REPLs (we're initially adding PostgreSQL REPL), which will act as a database client for the WebUI terminal client. The handle is responsible for issuing session certificates and calling the REPL implementation, which will connect to the database proxy server using the given configuration. This flow is similar to what is done for Kube Exec from WebUI, where we establish a "localhost" connection to the proxy using the database client.

Note

This implementation differs slightly from my original PoC and the short RFD description. Instead of directly dialing the database servers (duplicating the flow implemented by the Proxy server), we're dialing the proxy server to perform its job, so the handler + REPL act like regular database clients (such as psql). The main reason for this change was to try and keep the closest flow as tsh, and it also proved easier to implement (as the proxy server already has test coverage). This implementation detail should keep the UX of databases WebUI Access as described on the RFD.

sequenceDiagram
  participant UI as WebUI
  participant P as Proxy
  participant A as Auth Server
  participant S as Database Server
  
  UI->>+P: Establish WebSocket connection
  UI->>+P: Sends connect request
  P->>+A: Request certificates (interact with WebSocket if necessary for MFA)
  A->>-P: Session certificates
  P->>-UI: Session metadata
  P->>+P: Establish connection to Database Proxy server
  P->>+S: Connect to the database using its client (same flow as tsh)
  S->>-P: Database Connection
  
  loop REPL
    P->>-UI: Read
    UI->>P: Write
  end

Loading

The PostgreSQL REPL implementation is decoupled (at #49598), but this PR defines the function signature and who/how will be responsible for connecting to the database. So the changes here will directly affect the other PR.

[Tener]

First pass.

[Tener]

Suggested change

	// DatabaseREPLGetter is used to retrieve datatabase REPL given the
	// DatabaseREPLGetter is used to retrieve datatabase REPL given the

[greedy52]

some interface nits:

is REPLNewFunc necessary? can GetREPL return the REPLInstance?

would it be easier if REPLGetter is a func instead of an interface? Do we expect other functions for REPLGetter?

[gabrielcorado]

We don't initialize the REPL right away, so we can reuse this function to fill the SupportsInteractive field on the API. The WebUI uses this field to show the connect button on the database connect dialog.

[greedy52]

ok. if the only goal is the check SupportsInteractive at an earlier stage, could we have a dedicated call? something like:

type REPLGetter interface {
	IsDatabaseProtocolSupported(dbProtocol string) bool
	NewREPLInstance(context.Context, *NewREPLConfig) (REPLInstance, error)
}

[gabrielcorado]

Updated the interface, can you take a look?

[greedy52]

nit: this function doesn't look right to me. Each database should have different dbUsers and dbNames.

Could you double-check if this function is still needed? My understanding is that the current WebUI will only use the UnifiedResourceAPI so the caller "databases" API is no longer necessary. Even if we want to keep it, the caller should run the loop and use access checker for every database.

If we can fix that, I would prefer MakeDatabase to take in a bool for SupportsInteractive.

[gabrielcorado]

I've updated it. Now, the MakeDatabase only receives the values, and the MakeDatabases performs the database users/names listing (using the Enumerate functions). Note that I didn't update other places that directly call the MakeDatabase to use the same flow (as this seems out of this PR scope). That will be done in a separate PR.