[Defapp] Use real HPCON for PTY management; Have Monarch always listen for connections

[miniksa]

[Defapp] Use real HPCON for PTY management; Have Monarch always listen for connections

PR Checklist

• Closes [defapp] Clean up hpcon #9464
• Related to [defapp] Reconcile with process model/monarch-peasant glomming #9475 - incomplete fix
• I work here.
• Manual test

Detailed Description of the Pull Request / Additional comments

• Sometimes peasants can't manage to accept a connection appropriately because I wrote defterm before @zadjii-msft's monarch/peasant architecture. The simple solution here is to just make the monarch always be listening for inbound connections. Then COM won't start a peasant with -Embedding just to ask the monarch where it should go. It'll just join the active window. I didn't close 9475 because it should follow monarch policies on which window to join... and it doesn't yet.
• A lot of interesting things are happening because this didn't have a real HPCON. So I passed through the remaining handles (and re-GUID-ed the interface) that made it possible for me to pack the right process handles and such into an HPCON on the inbound connection and monitor that like any other ConptyConnection. This should resolve some of the process exit behaviors and signal channel things like resizing.

[DHowett]

How did the bot miss Psuedo

[miniksa]

How did the bot miss Psuedo

psuedoconsole was in expect.txt. I've removed it and will see what bot says about this.

[zadjii-msft]

I'd love to have more info on what difference duplicating the handles twice does, but the rest of this looks fine. Maybe spin one build with both duplications and one without, and see what the difference has. I don't want to leak processes when we're closed, but I also don't want to crash accidentally.

[miniksa]

I'd love to have more info on what difference duplicating the handles twice does, but the rest of this looks fine. Maybe spin one build with both duplications and one without, and see what the difference has. I don't want to leak processes when we're closed, but I also don't want to crash accidentally.

Dual duplication is a leak because I don't free one of the copies. I wanted the pty-api-like func to not trust the caller so it duped. The other dupe was because it HAS to on the way in the COM call. But my func signature isn't wil::unique_handle so nothing tracks ownership, the bare HANDLE is just a number. So anyone closing it ruins it for the whole app.

However, I realize I wrote the Pack API quickly for us only so I can refine that later if necessary and ONE dupe overall in this process space (that is tracked... in this case by holding the HPCON) is sufficient.

[DHowett]

@msftbot merge this in 1 minute

[ghost]

Hello @DHowett!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I won't merge this pull request until after the UTC date Mon, 24 May 2021 21:42:59 GMT, which is in 1 minute

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[ghost]

🎉Windows Terminal Preview v1.9.1445.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉Windows Terminal v1.11.2921.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download