feat(gstd): Introduce critical hook

[ark0f]

Release notes:
Introduce critical hook API. Similar to std::panic::set_hook but sets on per-message basis and takes into account specific program halts like gas outage, memory overflow, backend error and so on

[DennisInSky]

I am a bit confused by the behaviour of the HandleAction::Panic and the HandleAction::WaitAndPanic - in both cases we create a section with no the execute method being called, but in the second case it gets executed anyway. I can imagine this is a result of having the wait op before the panic, but it is absolutely not intuitive when you read the code w/o impl behind it

[DennisInSky]

I am a bit confused by the behaviour of the HandleAction::Panic and the HandleAction::WaitAndPanic - in both cases we create a section with no the execute method being called, but in the second case it gets executed anyway. I can imagine this is a result of having the wait op before the panic, but it is absolutely not intuitive when you read the code w/o impl behind it

To me it would be more comprehended if I had an option to register my compensation logic in relation to a future returned by some async call. This would clearly say that this functionality is about executing compensation with regards to this async/await. It doesn't seem the implemented functionality is relevant to any other cases.

[ark0f]

but it is absolutely not intuitive when you read the code w/o impl behind it

What about module docs?

[DennisInSky]

but it is absolutely not intuitive when you read the code w/o impl behind it

What about module docs?

This is not quite about docs - I read some code which uses some libraries and from reading it, it is vague what happens and how it works

[NikVolf]

User-facing API should be per-call

i.e. critical section is created, fired, and disposed once corresponding call handling is out of scope

[breathx]

Anything except comments above LGTM

[breathx]

@ark0f kind reminder to finish this awesome work

[NikVolf]

why is it stalling? @DennisInSky @breathx ?

[DennisInSky]

You know the difficulties arose during taking this design decision better, but I am still not quite happy with the solution as it still doesn't hihjlight that functionality is applicable to async code executed after await completion only. Probably, at least renaming the set_hook method into something like set_hook_for_async or moving it into the async_runtime module would give some hint to users about the context of this method.
I would also showcase that

set_hook(...);
panic!(...);

doesn't cause the hook to get executed. Whereas

some_async(...).await;
take_hook();
panic!(...);

will do

[ark0f]

Probably, at least renaming the set_hook method into something like set_hook_for_async or moving it into the async_runtime module would give some hint to users about the context of this method.

This would be a bit incorrect because it's not about async actually. It's about program state change (e.g. gr_wait for now which can be in sync code)