SSH Tunneling is quite slow

### Bug description

My users were reporting that dashboards were taking a long time to load. It seems that for each SQL query, Superset open a new SSH connection. That can be quite costly and can even trigger rate-limiting or rejection from the ssh server.

I added a side-car container using autossh to my setup, removed tunneling from the database connection parameters and pointed the database connections to that container instead of the actual database. My "cache warmup" periodic task went from 10 minutes to 3 minutes and users report a day-and-night difference. In addition, the logs are much more readable now :)

Could the tunneling implementation be improved by pooling the ssh connection across requests?

(I'm using Superset 5.0.0 but I mentioned Superset 6.0.0 in the bug details because that was the closest available option)

### Screenshots/recordings

_No response_

### Superset version

6.0.0

### Python version

I don't know

### Node version

I don't know

### Browser

Not applicable

### Additional context

_No response_

### Checklist

- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

The issue does not name implementation files, tests, or entry points. Start by locating Superset's SSH tunneling code and tracing how database queries create connections; define done as reusing or pooling SSH connections across requests without changing query results, while confirming improved dashboard or cache-warmup performance and avoiding repeated SSH setup.

Written by the indexing model from the issue text.