Unify ink_env::{eval_contract, invoke_contract}

[ascjones]

Unifies these two functions which already are both calling the same underlying function, except invoke passes () as the return type parameter.

If using the call builder API explicitly to invoke a message which does have a return value but you want to skip decoding it, as was the previous behaviour of invoke_contract, the user can either omit the call to returns::<R>() or explicitly set returns::<()>(). This will result as before in a no-op for the decoding so would be optimised away.

Closes #814

[HCastano]

Good stuff!

Heads up @xgreenx, this will cause some merge conflicts with #1133

[HCastano]

❤️ that users aren't exposed to ReturnType<T> anymore

[HCastano]

In the PR description you mention that "the user can either omit the call to returns::<R>()". Doesn't looks like this is the case, if I remove this line the example fails to compile

[ascjones]

Oh it appears that is only the case if the arg list is not set (which in this example it is) see https://github.com/paritytech/ink/blob/c0cccb74270f4ef9b92ea3dbde7a06b25f1bf091/crates/env/src/call/call_builder.rs#L438-L439.

Here is an example which calls explcitily but with no args so that compiles: https://github.com/paritytech/ink/blob/378d83f3fc204e18dce6f3946e6a0f27e333d7d6/examples/proxy/lib.rs#L80

I'm not sure why it was already this way, it would make sense to either allow it to be Unset either way and default to (), or require it to be set in all cases. What do you think?

[HCastano]

CI fails due to the contract-introspection example that's part of the ink-waterfall. Let's get this merged and then update the waterfall