contracts: Add new seal_call that offers new features

[athei]

Fixes #8421

This PR adds an unstable version of seal_call which has a new flags parameter that allows changing the behaviour of the call:

substrate/frame/contracts/src/wasm/runtime.rs

Lines 322 to 361 in 47a2e1d

	bitflags! {
	/// Flags used to change the behaviour of `seal_call`.
	struct CallFlags: u32 {
	/// Forward the input of current function to the callee.
	///
	/// Supplied input pointers are ignored when set.
	///
	/// # Note
	///
	/// A forwarding call will consume the current contracts input. Any attempt to
	/// access the input after this call returns will lead to `[Error::InputForwarded]`.
	/// It does not matter if this is due to calling `seal_input` or trying another
	/// forwarding call. Consider using [`Self::CLONE_INPUT`] in order to preserve
	/// the input.
	const FORWARD_INPUT = 0b0000_0001;
	/// Identical to [`Self::FORWARD_INPUT`] but without consuming the input.
	///
	/// This adds some additional weight costs to the call.
	///
	/// # Note
	///
	/// This implies `[Self::FORWARD_INPUT]` and takes precendence when both are set.
	const CLONE_INPUT = 0b0000_0010;
	/// Do not return from the call but rather return the result of the callee to the
	/// callers caller.
	///
	/// # Note
	///
	/// This makes the current contract completely transparent to its caller by replacing
	/// this contracts potential output by the callee ones. Any code after `seal_call`
	/// can be safely considered unreachable.
	const TAIL_CALL = 0b0000_0100;
	/// Allow the callee to reenter into the current contract.
	///
	/// Without this flag any reentrancy into the current contract that originates from
	/// the callee (or any of its callees) is denied. This includes the first callee:
	/// You cannot call into yourself with this flag set.
	const ALLOW_REENTRY = 0b0000_1000;
	}
	}

Additionally, this PR changes the behaviour of seal_input to no longer consume the input. It can be called multiple as long as the input wasn't forwarded by this new seal_call.

cc @Robbepop @cmichi

[Robbepop]

Nice PR!
Looking forward to finally have re-entrance protection and tail calls.
I don't really get why we need both FORWARD_INPUT and CLONE_INPUT though since either makes only sense with combination of TAIL_CALL or !TAIL_CALL.
Meaning: It does not at all make sense to clone the input if the call is a tail call and I also don't see a great reason to forward the input if the call is not a tail call. At least what is the gain for the user? It leaks implementation details on top of that.

[Robbepop]

In order to better support actor-based programming it might make sense to introduce yet another call flag ENQUE_CALL that is mutually exclusive with TAIL_CALL and that tells that the call is fire and forget and the caller does not care when the call actually takes place. This could be used to make calling other contracts more efficient in these cases and allows for efficient actor based smart contract programming. Though one problem remains: Who is gonna pay for the enqueued call?

[athei]

Meaning: It does not at all make sense to clone the input if the call is a tail call and I also don't see a great reason to forward the input if the call is not a tail call. At least what is the gain for the user? It leaks implementation details on top of that.

It is cheaper. You pay more weight by making a cloning call. If you know you don't need the input any longer you dan decide to forward even if it is no tail call. Yes CLONE_INPUT | TAIL_CALL does not make much sense but it still needs to be a bitfield because there are other combinations that make sense.

In order to better support actor-based programming it might make sense to introduce yet another call flag ENQUE_CALL

I think this is a topic on its own. We currently don't have any capabilities for asynchronous execution. It should be discussed in its own issue.

[cmichi]

Any code after seal_call can be safely considered unreachable.

For ink!, we should output a warning/error if there is contract code after an ink! function which does the forward. This would be a good follow-up for use-ink/cargo-contract#281.

[cmichi]

This PR adds an unstable version of seal_call […]

What's the condition under which the function will become stable?

[athei]

This PR adds an unstable version of seal_call […]

What's the condition under which the function will become stable?

Adoption by ink! that has shown that the new API is usable for its intended purposes.

[cmichi]

LGTM! Looking forward to the ink! side :-).

[gui1117]

Looks good to me

[gui1117]

I don't see where the cost of cloning compare to taking is charged, but I guess it is small enough to be negligible ? or is it because unstable ?

[athei]

It is not implemented, yet. I reserve the right to not completely flesh out weight handling for __unstable_ interfaces.

[gui1117]

makes sense, then all good, maybe a comment would prevent forgetting, but I'm fine

[ascjones]

LGTM

[athei]

bot merge

[ghost]

Trying merge.