refactor(accs): renamed .raw() function and added several new APIs

[Ansonhkg]

WHAT

unifiedAccessControlConditions requires a conditionType discriminator, but the Accs Builder's .raw() function returns “as-is” (no discriminator was added), and because the discriminator is only used for routing, it wasn't able to route to the correct code path to canonicalise the accs conditions.

// conditionType is read to decide which formatter to use...
switch (_conditionType) {
  case 'solRpc': return canonicalSolRpcConditionFormatter(cond, true);
  case 'evmBasic': return canonicalAccessControlConditionFormatter(cond as AccsDefaultParams);
  case 'evmContract': return canonicalEVMContractConditionFormatter(cond as AccsEVMParams);
  case 'cosmos': return canonicalCosmosConditionFormatter(cond as AccsCOSMOSParams);
  default: throw new InvalidAccessControlConditions(...);
}

That says, when passing unified accs, you must specify conditionType to be either evmBasic, evmContract, solRpc or cosmos.

The confusion occurred due to the the function .raw() name is misleading, it's not truly raw since it gets canonicalised and validated internally.

Changes

• renamed raw() -> .unifiedAccs()
• added .evmBasic() function
• added .evmContract() function
• added .solRpc() function
• added .cosmos() function

Test

Use the result from .evmBasic to encrypt, then use the result from .unifiedAccs to decrypt. Both should produce the same accs so it should work interchangeably.

NETWORK=naga-dev bun test ./e2e/src/v7-compatability.spec.ts

[glitch003]

this seems pretty straightforward and looks good. we should probably review how much of these solana and cosmos access control conditions we want to keep supporting but that's def a separate topic.