Creating Azure.Functions.Cli.Abstractions needed for new testing framework

[aishwaryabh]

Issue describing the changes in this PR

resolves #4327

This PR is the first part of a series of PRs to set up a new testing framework for the Azure Functions CLI. This is the larger PR, which contains all the changes for the testing framework and the updated func start E2E test, if you would like to take a look at how it all fits in! I just decided to split it up since it would be easier to review and get feedback this way.

The Azure.Functions.Cli.Abstractions.csproj contains the abstractions that are copied from the .NET SDK. The only difference is Command.cs in how the ProcessStartedHandler is initialized and called, since we have to account for the process being async. Once the host starts, we use the ProcessStartedHandler to get direct access to the process that has been created and the logs that are emitted from that specific process as well, which is why we must await the host to be ready first before checking any logs.

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

[liliankasem]

The only difference is Command.cs in how the ProcessStartedHandler is initialized and called, since we have to account for the process being async. Once the host starts, we use the ProcessStartedHandler to get direct access to the process that has been created and the logs that are emitted from that specific process as well, which is why we must await the host to be ready first before checking any log

Can you commit the original in first and either a) in a new PR make the change youre talking about here or b) make that change in a new commit so that we can review what changed from the original file

[liliankasem]

I think we should create folders to organize these files i.e.

• Environment -> Env; EnvironmentProvider; IEnvironmentProvider
• Command -> Command; ICommand; CommandResult; CommandLoggingContext
• Logging -> IReporter; Reporter; StreamForwarder; AnsiConsole;
• Extensions -> AnsiExtension; CollectionExtensions

The rest can stay at root

[aishwaryabh]

The only difference is Command.cs in how the ProcessStartedHandler is initialized and called, since we have to account for the process being async. Once the host starts, we use the ProcessStartedHandler to get direct access to the process that has been created and the logs that are emitted from that specific process as well, which is why we must await the host to be ready first before checking any log

Can you commit the original in first and either a) in a new PR make the change youre talking about here or b) make that change in a new commit so that we can review what changed from the original file

yes! so og command.cs is the original command.cs. And changes made to command.cs are the changes i made.
Not sure if I should also have a localized strings file like how .NET has. We can also create a work item for this change in another PR as well

[liliankasem]

I think we should create folders to organize these files i.e.

• Environment -> Env; EnvironmentProvider; IEnvironmentProvider
• Command -> Command; ICommand; CommandResult; CommandLoggingContext
• Logging -> IReporter; Reporter; StreamForwarder; AnsiConsole;
• Extensions -> AnsiExtension; CollectionExtensions

The rest can stay at root

Example