feat: port forwarding dropdown

[code-asher]

What this does:

• Adds a web socket to the agent that scans for listening ports on an interval
• Displays those ports in a popup when you open said popup
• The popup also lets you manually open ports in case the detection is not working

Todo:

• [ ] Fails on darwin, I think because the netstat package does not support darwin. Not sure how to fix this yet.
• [ ] Add comprehensive frontend test similar to the terminal test (only the individual parts are tested right now).
• [x] Probably need to filter out some ports like 22.
• [ ] Not sure if the proxy backend is built out yet so the ports link to a temporary non-working URL right now.

Closes #1624

[ammario]

What's the status of this feature?

[code-asher]

This is blocked on being able to actually open a link to a port. I messed up because I thought work on that was underway but it seems actually not to be? I was thinking I could just add it myself but I have not found the time to work on that yet.

IDK how we plan on doing the sub-domain version but since we already have /apps I imagine it would not be too much work to add a path-based version with a port number in it, something like /proxy/{port-number}.

[ammario]

This is blocked on being able to actually open a link to a port. I messed up because I thought work on that was underway but it seems actually not to be? I was thinking I could just add it myself but I have not found the time to work on that yet.

I have no clue where the other work sits. Perhaps @tjcran can shed some light here. It's unfortunate to watch the ever-increasing merge conflicts erode this code. Dev URLs are a necessary feature for about half of our v1 users that are browser only.

IDK how we plan on doing the sub-domain version but since we already have /apps I imagine it would not be too much work to add a path-based version with a port number in it, something like /proxy/{port-number}.

Yeah, the wildcard subdomain setup always sucks. I think we all know the limitations of the path-based solution, but it could be an interesting fallback when the wildcard domain isn't setup yet. If we did that, we would want to make it very clear_ to the user that they could setup a path-less solution.

[tjcran]

@ammario i believe @kylecarbs is doing the work for that. I'll let him comment.

[kylecarbs]

That work is partially implemented by the #1773 PR. The wildcard subdomain routing and authentication still needs to be added. It's a bit of an awkward UX for our current setup experience, so I think we should align on how we'll do that before continuing. We can replicate the v1 experience, but it wasn't very smooth.

[kylecarbs]

To clarify, this is fully blocked on me, not @code-asher!

[kylecarbs]

This should stay open until we make headway on #2986. It'll certainly come into play!

[github-actions[bot]]

This Pull Request is becoming stale. In order to minimize WIP, prevent merge conflicts and keep the tracker readable, I'm going close to this PR in 3 days if there isn't more activity.