Connect: Create dedicated functions for connecting to resources

[gzdunek]

This PR makes connecting to the node faster (without using commandLauncher), since we know all the details needed to establish an SSH connection.
I also created functions for dbs and kubes, so we can share the same code between resource tables/search bar.

I'm only unsure about the naming - I wanted to avoid names like createDatabaseDocument as we already have such functions in DocumentsService. They only create documents objects, but here we do more (we change the workspace, create a document and set it as active). It seems to me that all these operations can live in a function connectToX.

---

For now I left ssh-ssh command as it is used by QuickInput.

[ravicious]

Looks good, the only real change I'd make is not using the spread operator.

[ravicious]

db includes a whole bunch of stuff that's not required by the second argument to connectToDatabase. Spreading it like this also makes it harder to find references to fields returned from makeDatabase.

I think it might be a good idea to do something like this:

Suggested change

	connectToDatabase(
	appContext,
	{ ...db, dbUser },
	{ origin: 'resource_table' }
	);
	const { uri, name, protocol } = db;
	connectToDatabase(
	appContext,
	{ uri, name, protocol, dbUser },
	{ origin: 'resource_table' }
	);

[gzdunek]

I started with a direct assignment, but then switched to the spread operator 😏 Changed.

[ravicious]

idk if it's just me but I'm used to params being "the" params for the given function. I like the current split into an object describing the target and a separate object with irrelevant stuff,

Maybe something like options/opts would work better here? ChatGPT suggests just calling it telemetryOptions/telemetryData, I suppose we could go with just telemetry as well.

[gzdunek]

telemetry sounds good.

[ravicious]

When I was working on the prototype, I totally forgot that activateItem already changes the workspace as well. 👍

[ravicious]

I kinda wish this whole logic was more centralized, as in there would be a single place encapsulating all this logic. Because right now we create a gateway doc here, if a matching connection exists then we pass the execution to connectionTracker which by itself also handles creating a doc if one is missing.

But this is good enough for now and refactoring this would require a much bigger effort.

[gzdunek]

Agree :(

[ravicious]

Same consideration as for db above.

[ravicious]

Why node and not server? I know that we call them nodes on the Teleport side but AFAIK through Connect codebase we consistently call them servers.

[gzdunek]

No particular reason, changed to server.

[ravicious]

As I mentioned, it'd probably be a good idea to be more explicit here and other places in this file as well with regards to not spreading and instead explicitly listing needed fields.

[ravicious]

I'm only unsure about the naming - I wanted to avoid names like createDatabaseDocument as we already have such functions in DocumentsService. They only create documents objects, but here we do more (we change the workspace, create a document and set it as active). It seems to me that all these operations can live in a function connectToX.

I think that's a good decision. I was wondering what would be the best place for those "global" functions. Previously, the command launcher was a place for those global actions, at the moment I think WorkspacesService is good enough to hold that.