feat: display status of sending request steps - INS-3635

[ihexxa]

Changes

• Enabled http request timing observing
• Enabled GQL timing observing
• Enabled mock route test timing observing
• Added after-response script step

Ref: INS-3821, INS-3635

[jackkav]

feedback

• language is a bit unclear, visually we are looking at a single execution with many steps/phases
• timingrecord is unclear name, rename record to step/phase
• avoid try catch finally for control flow, replace with a clear begin and end process events
• post request script takes double the time taken that it should when i add a setTimeout
• endedAt is not a safe type to be setting to the number 0 because it is used as a date, better would be to make null or a duration rather than a timestamp
• isDone is duplicate data, since we can infer that if endedAt exists then it must be true.
• total time taken breakdown in hover?

[jackkav]

Still todo

fix bug where navigating away from a running request loses the loading state. below steps related:

• eliminate the runningRequests variable, replace with execution map
• extract the watcher as a hook
• consider object rather than array from executions, because of indirection (last)

[jackkav]

Couple changes left

• perhaps use an alternative ui method of overlaying instead of errorboundary
• fix logic in response pane so it overlays over last request

[jackkav]

current problem is we use this in three places so they overwrite each other and only one works. I've looked at making it an array but then we have a a few new problems. Wondering if theres a better way, I've looked at file watching the timeline and that has a couple new problems too. I'm sure theres a simpler way I'm just not seeing it.

[ihexxa]

Let's see if there is a simple solution or I might propose to move forward with the main requirement firstly then move to changes after e592cab.

[jackkav]

We moved it to main, in order to benefit from the ipc event emitter pattern. This way its consistent across all usages of the hook at open windows/instances.

Whats left is some tidying up of names to make it consistent, and some testing.

The big benefit of this approach is we can easily change the persistence layer later to use another state store like the timeline instead of the executions map.

Thanks @gatzjames for the ideas and support.