Copilot chat: ChatController

[TaoChenOSU]

Motivation and Context

We would like developers to be able to deploy SKaaS that is not tightly coupled to Copilot Chat.

Description

1. Group Chat related components to their own folders.
2. Strip out anything related to the current Chat features out of the SemanticKernelController.
3. Create a ChatController specifically to invoke the ChatSkill.
4. Refactor the WebApp to use the new ChatController. Make the service invocation pattern more consistent.
5. Remove the SKBotAudienceMember and refactor ChatStatus. Note that this component does not currently take any effect. But this component will be useful moving forward with the multi user support.
6. Disable implicit using.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows SK Contribution Guidelines (https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
• The code follows the .NET coding conventions (https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) verified with dotnet format
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[Vivihung]

Thanks for the refactory. I've left some comments

[Vivihung]

I worried the new project structure will confuse developers who are not familiar with the codebase. It's not straightforward to have two api project of the same app. And it's not common to include Controllers in a lib. I will let these big changes in but will work with Adrian offline to see if there's any mitigation.

Given said that, it's a great effort to separate components apart. Appreciate the huge refactory here.

[craigomatic]

I worried the new project structure will confuse developers who are not familiar with the codebase. It's not straightforward to have two api project of the same app. And it's not common to include Controllers in a lib. I will let these big changes in but will work with Adrian offline to see if there's any mitigation.

Given said that, it's a great effort to separate components apart. Appreciate the huge refactory here.

I agree with Vivian, it's going to feel strange to have controllers in a project that does not appear to be runnable (I don't see a Program.cs)

Another pattern to consider:

• Everything under your new copilotchat folder becomes 1 or more services (ChatService, DocumentService, etc) and anything aspnet specific disappears (controllers, etc)
• Your services know nothing about the underlying hosting mechanism - it could be a console app, windows forms, aspnet, etc
• They do the work you have in the controllers currently
• We ship another aspnet app that uses the services so there remains a way for devs to deploy copilot chat

And if the objective is to allowing devs to deploy SKaaS with or without copilot chat, does this also imply that we should move the webapi project out of the copilot-chat-app folder?