Add workflow system info in Workflow Execution context

[khushboobhatia01]

This PR adds workflow engine system information to WorkflowExecution context. Ref https://github.com/StackStorm/st2/discussions/5373

{
    "engine_info": {
        "hostname": "st2", 
        "pid": 1085262
    }, 
    "parent": {
        "user": "stanley", 
        "pack": "examples"
    }, 
    "st2": {
        "action_execution_id": "6174ce479195da5bbddf5443", 
        "api_url": "http://127.0.0.1:9101/v1", 
        "runner": "orquesta", 
        "workflow_execution_id": "6174ce48f3b5fca8fa795f97", 
        "user": "stanley", 
        "action": "examples.orquesta-sequential", 
        "pack": "examples"
    }
}

This information will be used to identify orphaned workflow execution.

[m4dcoder]

@khushboobhatia01 Can you also clean up this PR because the branch is littered with Trigger/Retrigger CI? This will get into the commit history for master branch.

[Kami]

I won't have time to perform a detailed review, but just two quick comments / questions:

1. Performance implications

It appears that depending on the object passed to the function, we will either perform 1 or 2 additional GET one and 1 (2? I don't know why we need that delete at the end in finally) additional UPDATE query each time handle_workflow_execution and handle_action_execution is called.

A while back I spent a substantial amount of time of profiling and optimizing performance of that code path (which is considered a hot code path since it's executed often and has major performance implication on how long running / scheduling executions and workflows takes).

And per @m4dcoder coder, that code can be executed multiple times (each time execution it's picked up by workflow engine) so this makes it even more problematic.

Even though we made a lot of performance improvements which should make those GET and UPDATE queries much faster now, we should still think about it some more and see if there is any way to reduce number of queries and make that code more efficient.

So in short, each time we touch those functions we should think hard when adding new DB operations and if they are really needed.

2. Code formatting / style

I don't think we should use a decorator.

It makes code harder to read and understand.

It should be a regular function / method (or two of them so we can get rid of *args and **kwargs stuff which also makes code hard to read and understand) which gets called in places where it's needed.

[cognifloyd]

@khushboobhatia01 what are your plans with this PR? Do you know when you'll be able to pick it up again and address some of the feedback here?

[CLAassistant]

All committers have signed the CLA.