Add a system message to session restore

[lhecker]

This adds a system message which displays the time at which the
buffer snapshot was written to disk.

Additionally, this PR moves the snapshot loading into a background
thread, so that the UI thread is unblocked and that multiple
tabs/panes can load simultaneously.

Closes #17031
Closes #17074

Validation Steps Performed

Repeatedly closing and opening WT adds more and more messages.
Currently, the messages get somewhat corrupted due to a bug
in our line-wrap handling, or some similar part.

[carlos-zamora]

Suggested change

	const auto core = winrt::get_self<ControlCore>(_core);
	const auto core = winrt::get_self<ControlCore>(self->_core);

Shouldn't we use self here?

[lhecker]

We don't need to. WinRT types like this are immovable and so the this pointer will refer to the same object after the suspension as it did before. self is just another safe/managed pointer.

[zadjii-msft]

1% worried about starting the connection on the BG thread instead of the window thread, but I don't actually see anything in ConptyConnection::Start that looks like it needs the main thread.

[lhecker]

I'm also quite worried about this but looking at how it writes _hOutputThread and so on, I think I'll add some code to switch back to the main thread. While that adds to the latency, I think it's worth it.

[zadjii-msft]

Should we also start with a \n, so that the message always gets printed on a newline? (I'm imagining a scenario where the user was at the prompt, so the scrollback now looks like

C:\users\me>some-long --command [Restored 1/23/45 6:07])
Microsoft Windows [Version 10.0.26201.5000]
(c) Microsoft Corporation. All rights reserved.

C:\users\me>

[lhecker]

The serializer will always end the dump in a trailing newline. However, if you look further down below, you'll see that I check that the cursor is at the start of the line/row, just to be sure, and otherwise I'm printing another newline.

[zadjii-msft]

should we explode entirely if this fails? or just skip printing the "[restored ]" message?

[lhecker]

Yes, I think this is fine. If either of these fails, the file is probably not safe to read anyway.

[zadjii-msft]

Do we need to put the args in here too? I'm not sure if there's any locales where the translation would require re-ordering those bits

[zadjii-msft]

theoretically you could do a https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/concurrency-2#programming-with-thread-affinity-in-mind:

{
    winrt::apartment_context ui_thread; // Capture calling context.

    co_await winrt::resume_background();
    
    // Do compute-bound work here.

    co_await ui_thread; // Switch back to calling context.

    textblock.Text(L"Done!"); // Ok if we really were called from the UI thread.
}

but meh

[lhecker]

And we won't have to replace that with wil::apartment_context for some weird reason soon right?
...
...
...right?

I'll change it, because I get the feeling this is how it's supposed to be done.

[DHowett]

Leonard, can we file a followup task to replace all instances of "save the dispatcher and return to it" with this more correct thing?

[lhecker]

There's actually only 2 places which fit this pattern:

• AppHost::_RenameWindowRequested
  This one should probably not yield to a background thread at all. It would probably get fixed if/when/ever we clean up the peasant/monarch code.
• TerminalPage::_PasteFromClipboardHandler
  Here, I'm not entirely sure whether PasteFromClipboard is always raised from the foreground thread. It's probably not, so I think it can't use winrt::apartment_context.