feat(evm): Add PermissionsPolicy for permissioned EVM

[facs95]

Description

Closes: #XXXX

With this we take a similar approach to CosmosWasm to make it possible to make the EVM permissioned. This proposes to have now within the EVM params a permissions field with the following types.

// Permissions defines the permission policy of the EVM
// for creating and calling contracts
type Permissions struct {
	// create defines the permission policy for creating contracts
	Create *PermissionType
	// call defines the permission policy for calling contracts
	Call *PermissionType
}

// PermissionType defines the permission type for policies
type PermissionType struct {
	AccessTypes      AccessType
	WhitelistAddress []string 
}

type AccessType int32
const (
	AccessTypeEverybody        AccessType = 0
	AccessTypeNobody           AccessType = 1
	AccessTypeWhitelistAddress AccessType = 2
)

This allows for a granular control over permissions for create and call opcodes while also making it customizable for other customers of the evmosOS (this will improve in future versions).

In our version of the implementation we are passing this into the opcodeHooks for it to be called within the CREATE and CALL opcodes. If AccessTypeWhitelistAddress is chosen, then we will check first that if the signer of the tx is a whitelisted address, if not then we check if the caller (contracts performing internal calls) has permissions.

	switch permissions.Create.AccessType {
	case types.AccessTypeEverybody:
		return func(caller string) bool { return true }
	case types.AccessTypeNobody:
		return func(caller string) bool { return false }
	case types.AccessTypeWhitelistAddress:
		addresses := permissions.Create.WhitelistAddresses
		isSignerAllowed := slices.Contains(addresses, signer)
		return func(caller string) bool {
			return isSignerAllowed || slices.Contains(addresses, caller)
		}
	}
	return func(caller string) bool { return false }

NOTE: This is blocked by evmos/go-ethereum#28

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• tackled an existing issue or discussed with a team member
• left instructions on how to review the changes
• targeted the correct branch (see PR Targeting)

Reviewers Checklist

All items are required.
Please add a note if the item is not applicable
and please add your handle next to the items reviewed
if you only reviewed selected items.

I have...

• added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• confirmed all author checklist items have been addressed
• confirmed that this PR does not change production code
• reviewed content
• tested instructions (if applicable)
• confirmed all CI checks have passed

[0xstepit]

Nice approach @facs95! I have one question. If the authorization is associated with the sender, how a contract that requires to create new ERC20 tokens, like an AMM, can work?

[facs95]

Reimplemented with a new approach based on @0xstepit suggestions! Please take a look and give me feedback. Will implement tests afterwards. Tested locally and works as expected. I will add a brief description tomorrow to explain it better. cc. @fedekunze

Pay special attention to:

• proto files
• state_transition.go
• permissions.go
• opcode_hooks.go

[0xstepit]

Looks good, great job @facs95 !

[GAtom22]

Great work @facs95!!

Left a few comments

Also, we'll need to update the module version and add the corresponding store migration

[fedekunze]

utACK