250 improve error handling in chain extension

[gianfra-t]

Closes #250 .

This PR proposes to use the existing ChainExtensionError as the enum discussed in the issue, which is now renamed ChainExtensionOutcome which also holds the Success variant.

For this, each value is mapped to a corresponding integer, and later we use the corresponding ChainExtensionOutcome as u32 when returning.

A conversion from u32 to ChainExtensionOutcome or it's inner variants is also defined

[ebma]

Looks good overall 👍
A few remarks that came to my mind.

1. It's probably a good idea to return a value that indicates 'success' for chain extension functions that are changing state. I can see that Astar is returning a 'Success'-error for each mutating function.
2. We might also want to consider implementing a conversion from number -> Error type, like eg. here. This way, the error enum could also be re-used in ink! smart contracts that want to interact with our chain extension. (This is not super useful until we extracted the chain extension into an extra crate here, but still nice to have).

[gianfra-t]

I understand the conversion back from number to chain extension error, and I think also returning a success is more readable than 0. Then I would propose to rename the enum to something that is not ChainExtensionError, so that it does not become confusing (naming it Outcome, let's say)

[ebma]

Then I would propose to rename the enum to something that is not ChainExtensionError, so that it does not become confusing (naming it Outcome, let's say)

Sure. I would be fine with ChainExtensionOutcome. We could also do ChainExtensionRetVal or ChainExtensionReturnValue. Not sure what's best, WDYT @gianfra-t and @b-yap?

[gianfra-t]

I've added the conversion from u32 to ChainExtensionOutcome and adjusted the code to the refactor made in a recently merged PR.

[b-yap]

No complaints from me.

Except for that 1 CI error

[ebma]

I think the CI basically passed because only saving the cache failed, right? Maybe we can just merge it like this

[gianfra-t]

Does that step in the CI just cleans after the cargo build? In that case yes we should already merge it. Otherwise we can re-check again.

[ebma]

I think it's fine to ignore. I'll merge it now.