feat(world): add CallBatchSystem to core module

[yonadaa]

closes #1160
closes #1470

The BatchCallSystem enables calling many systems in a World in a single transaction.

It leverages callFrom to execute each system call with the user as msgSender(). Users delegate to the BatchCallSystem system, then call batchCall with the resource selectors and calldata for the systems they wish to call.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4ce27d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 29 packages

Name	Type
@latticexyz/world	Major
@latticexyz/cli	Major
@latticexyz/dev-tools	Major
@latticexyz/store-sync	Major
@latticexyz/store-indexer	Major
@latticexyz/abi-ts	Major
@latticexyz/block-logs-stream	Major
@latticexyz/common	Major
@latticexyz/config	Major
create-mud	Major
@latticexyz/ecs-browser	Major
@latticexyz/faucet	Major
@latticexyz/gas-report	Major
@latticexyz/network	Major
@latticexyz/noise	Major
@latticexyz/phaserx	Major
@latticexyz/protocol-parser	Major
@latticexyz/react	Major
@latticexyz/recs	Major
@latticexyz/schema-type	Major
@latticexyz/services	Major
@latticexyz/solecs	Major
solhint-config-mud	Major
solhint-plugin-mud	Major
@latticexyz/std-client	Major
@latticexyz/std-contracts	Major
@latticexyz/store-cache	Major
@latticexyz/store	Major
@latticexyz/utils	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alvrs]

should we make this a root system and then do this so the users don't need to create a delegation?

(bool success, bytes memory returnData) = address(world).delegatecall(abi.encodeCall(
  world.call,
  (
    _msgSender(),
    resourceSelector[i],
    funcSelectorAndArgs[i]
  )
));
if(!success) revertWithBytes(returnData);

We can actually do both, have a BatchCallSystem and a BatchCallRootSystem, and install then in installModule and installRootModule respectively

[holic]

do we need this to be a module? if we intend to use this for deploys anyway, would it make sense to just have this under core/implementations as a plain root system? I also can't imagine you'd wanna install this more than once anyway?

[alvrs]

yeah it can also be part of the core module

[yonadaa]

I like this approach without the delegation. I'm going to add the root version to the core module.

I'll also remove the non-root version, because the root version will be installed on worlds by default.

[holic]

would it be worse on calldata length if this was something like

struct SystemCall {
  bytes32 systemId;
  bytes callData;
}

function batchCall(SystemCall[] memory systemCalls) public {

(this feels cleaner but I would prob optimize for calldata/gas here, since these calls will be abstracted away anyway)

[holic]

same question as before: would it be better or worse gas-wise to have an array of SystemCall structs instead of two arrays? I assume a little worse on calldata but we wouldn't have to do a length check on the arrays to make sure they match (though I guess the whole thing would revert with an out of bounds error in that case?)

[alvrs]

my feeling is it would be a little better calldata wise because the structs are encoded like tuples, so there shouldn't be overhead on the encoding of the individual elements, but we might save one word because we only have one array (and therefore only one length encoding)

[yonadaa]

Going to implement the struct for the calldata improvements and to improve usability (only dealing with a single array)

[holic]

should we add some tests to make sure this goes through access control checks properly and fails on system calls we don't have access to?

[yonadaa]

I wasn't sure where to put this file specifically for the struct.

[holic]

Realizing now we have two things named SystemCall

@alvrs should we keep this one named that way and the other lib named as SystemCaller or SystemCallLib?

[alvrs]

i'd propose calling this one SystemCallData (aligned with how the tablegen structs are called, and also alllgins with "callData")