New activity output wrapper utils and execute step base

[MicroFish91]

Summary:

• New activity utils and activity try catch wrapper
• New execute step base for automatically handling displaying of output logs/activityChildren corresponding to the execute step's success/fail state
• Consolidate activity related util files into an activity folder
• One example of implementation (LogAnalyticsCreateStep)

[nturinski]

I think you can just do a type import for this (and a lot of these since it's all interfaces/abstract)

[nturinski]

There's nothing in here that really is a cause for blocking, so I'll just approve it. If you do make changes, I'll look at them again later

[nturinski]

Is there really any need to make tryCatchActivityWrapper a util function? I feel like it makes it a little bit more complicated than just having a try/catch clause in execute here. I don't think that you could really use this util function with anything other than this ExecuteActivityOutputStepBase.

[MicroFish91]

That's a good point. I originally implemented it without the execute step base but forgot to extract this logic to sit together with it.

[nturinski]

We talked about refactoring it, but I honestly don't have a very strong opinion about it. I think this does make it a bit more clear about the success and fail states. I think with my comment above, I'd just do the try/catch in the execute like this:

try {
  await this.executeCore(context, progress), context, this.options);
  output this.initSuccessOutput(context)
} catch (theseHands) {
  output this.initFailOutput(context)
}

I think after seeing this base step, that I agree that this is more clear. Though I don't really like the naming-- not sure what it is "initializing" really. I think createFailOutput or createFailChild maybe makes more sense to me?

[nturinski]

Overall, this feels much cleaner to me. Couple of things you can change:

• You can do this.displayOutput at the end so you don't have to call it twice like this. I'd do something like this;

       let output;
       try {
            await this.executeCore(context, progress);
            output = this.createSuccessOutput(context);
        } catch (e) {
            output = this.createFailOutput(context);
            if (!this.options.shouldSwallowError) {
                throw e;
            } 
        } 
       
        this.displayOutput(context, output)    

• You could also get rid of success and fail as properties on the interface. I personally think this is a bit cleaner. I don't think the finally clause will run

[MicroFish91]

There's some rare cases where I might want to add onto the output log messages inside of executeCore, so I think it might be useful to have the success and fail outputs initialized and available ahead of time so they can be accessed within that method.

[nturinski]

Overall, I do prefer this and think it's cleaner.