feat: introduce encode stage

[omerfirmak]

1. Purpose or design rationale of this PR

JSON encode/decode step takes %50 of CCC runtime. Splitting it to a seperate stage makes tracing the new bottleneck, which is a more comfortable position to be in since we didn't attempt to optimize it yet.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

[jonastheis]

JSON encode/decode step takes %50 of CCC runtime

How exactly are you benchmarking these improvements? I couldn't find any benchmarks or tests disguised as benchmarks on this. Would be great to have some objective measure to look at.

[omerfirmak]

JSON encode/decode step takes %50 of CCC runtime

How exactly are you benchmarking these improvements? I couldn't find any benchmarks or tests disguised as benchmarks on this. Would be great to have some objective measure to look at.

Benchmarks are done on live mainnet data, so there is no clean way of putting that in a reproducable way.