Update the Device Attributes report

[j4james]

Description of the new feature/enhancement

Up to now, we've been identifying as a VT100, since we haven't fully met the conformance requirements for any of the higher level devices. But with the recent support that's been added for several VT extensions, I think it's time to consider an updated DA response.

The structure of a DA report is as follows: the first parameter value indicates the conformance level with a number in the range 61 to 69 (representing levels 1 to 9); subsequent parameters indicate the supported feature extensions. The early VT terminals didn't follow this standard, but their initial DA parameter would have always been below 60.

We still don't meet the requirements for level 2, so the first parameter in our DA response will have to be 61. But we do now support a number of feature extensions, which we can indicate with additional parameter values. Some of the more useful ones include:

7 = Soft Fonts (since PR #13965)
28 = Rectangular Editing (since PR #14285)
32 = Text Macros (since PR #14402, if accepted)

Applications that wish to take advantage of these features would be able to do so automatically if they could tell from the DA report that the terminal supported the necessary extensions.

Proposed technical implementation details (optional)

Updating the DA report seems like it ought to be a trivial change. However, the complication for us is this it's handled on the conhost side, but it needs to take into account the capabilities of the conpty client. For example, conhost supports Soft Fonts, but they won't work over conpty unless the conpty client also supports them (and for Terminal that's dependent on the configured renderer).

My proposed solution for this is that we fire off a DA request to the conpty client on startup (similar to the way we sometimes send a CPR request on startup). We then save the relevant information from the client's response (for now just the Soft Font support), and use that to determine what features we can include in our DA response.

Does that seem like a reasonable approach to take?

[zadjii-msft]

Seems sensible to me, though, we might want to be careful to be sure that the client can reply. Maybe we should gate it on --inheritCursor? er. Maybe not. There was some WSL issue IIRC that precipitated the need for --inheritCursor, rather than passing it all the time. Like, some scenarios where there was nothing actually processing the input, so if ConPTY just waits on startup for a reply, conpty might just HANG if no one ever replies. We might need some sort of timeout on startup to have conpty bail if conpty fires off a DA and doesn't get a response.

Maybe we could just not block startup on this. Fire off the DA, and just keep going. If we get a reply, then great, if not, then just keep 'er movin.

[j4james]

Maybe we should gate it on --inheritCursor? er. Maybe not.

Yeah, --inheritCursor isn't an option since it doesn't seem to get used most of the time, and this has to be called every time if we want it to work correctly every time.

We might need some sort of timeout on startup to have conpty bail if conpty fires off a DA and doesn't get a response.

That kind of sucks, because if that really is necessary, we're again left with a solution that isn't going to work some of the time. And any apps that rely on the DA information being correct are going to then have inconsistent behavior - sometimes they'll work and sometimes they won't.

I'd love to know under what conditions this is expected to fail, and whether that's fixable. Like could we maybe delay sending the DA request until the client has reached a certain steady state?