feat: param validation for all RPC methods

[andreabadesso]

Acceptance Criteria

• We should include parameter validation for all RPC methods
• If a rpc request fails validation, the handler should throw a specific error

Checklist

• If you are requesting a merge into master, confirm this code is production-ready and can be included in future releases as soon as it gets merged
• Make sure either the unit tests and/or the QA tests are capable of testing the new features
• Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.

[r4mmer]

Maybe we should use .nullish() instead of .nullable().optional()

[r4mmer]

Suggested change

	create_mint: z.boolean().optional().default(true),
	create_mint: z.boolean().default(true),

The deault already makes the field optional.

> foo = z.object({ bar: z.number().default(123) })
> foo.parse({})
{ bar: 123 }

[r4mmer]

Why not use the null as default?

[r4mmer]

Maybe we should add a transform on the schema.

const foo = z.object({
  // schema definition
}).transform(input => ({
  name: input.name,
  address: input.address,
  changeAddress: input.change_address,
  // ... other keys
}));

This way when we parse the object it already comes out as camelcase.

[r4mmer]

suggestion(non-blocking): Maybe we should add this to the transform.

We could transform the data to be a params.options with these fields, which would make the call something like:
wallet.createNewToken(params.name, params.symbol, params.amount, params.options);

This would make any changes (new arguments, etc.) only need to be changed on the schema and transform.
But this is just a suggestion, maybe the flat object is better for testing or using elsewhere.

[r4mmer]

Suggested change

	}).refine(
	(data) => {
	if (data.type === 'index') {
	return data.index !== undefined;
	}
	if (data.type === 'full_path') {
	return data.full_path !== undefined;
	}
	return true;
	},
	{
	message: "index is required when type is 'index', full_path is required when type is 'full_path'",
	}
	);
	}).refine(
	(data) => {
	return (data.type !== 'index' || data.index !== undefined);
	},
	{
	message: "index is required when type is 'index'",
	}
	).refine(
	(data) => {
	return (data.type !== 'full_path' || data.full_path !== undefined);
	},
	{
	message: "full_path is required when type is 'full_path'",
	}
	);

We can chain the refines so the message is more descriptive of the case

[r4mmer]

I know fullpath is not implemented, but are we going to expect a m/44'/280'/0'/0/index?
If so, maybe we should validate this here, or at least comment that we should add validation later

[r4mmer]

This schema of type + optional fields may be better expressed as a discriminated union.
This would make the refines obsolete since in the index type the index argument would be required.

[r4mmer]

If you don't want to put the entire function inside a try catch and handle parsing errors at the end you could use safeParse which returns a success flag with the data or error.

What do you think?

[r4mmer]

Maybe we should expose these types in the lib index instead of importing from the internal path.