Draft service warning emit

[yao-msft]

Summary of the Pull Request

PR Checklist

• Closes: Link to issue #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[OneBlue]

I like this structure because it will nicely integrate with the EMIT_USER_WARNING() macros that we have.

Sadly there's one tricky that we need to consider: If the caller doesn't read from the handle, we need to be able to Cancel the IO so that we don't get stuck when trying to terminate a session if the caller doesn't read from the HANDLE and the pipe gets full.

(This is how we do it on the regular session handles

The issue would be the same if we decided to use a COM callback, we would need to keep track of the callback, and cancel it if the session terminates (pointer to how we terminate COM callbacks today

One way we could make this work would be by adding a pointer to the WSLCSession to COMServiceExecutionContext, and do something like this:

HRESULT WSLCSession::CreateContainer(const WSLCContainerOptions* containerOptions, IWSLCContainer** Container)
{
    COMServiceExecutionContext context(this);
[...]
}

So that way, we can register the COM callback / IO with the session when we emit a warning, and so it will be correctly cancelled if the session terminates.

Regarding the pipe vs COM callback, I think I have a small preference for the COM callback, since we already do that in other places (like for the pull / build callbacks), and at least it won't force the caller to create a thread if no warning are emitted

[OneBlue]

Unfortunately I don't think a global handle will work here (long term, we should add support for warnings when creating a container, and in that code paths, multiple containers can start at the same time), so I would recommend making the warning pipe / COM pointer a regular field, so only the thread that sets it can use it