refactor(coordinator & prover): RESTful API

[colinlyguo]

Purpose or design rationale of this PR

What does this PR do?

This PR optimizes the communication between coordinator and prover.

Why does it do it?

1. Currently, the coordinator can't deploy multiple replicas, for high availability, we need to enhance it.
2. Changed prover client to support RESTful API according to coordinator refactor.

How does it do it?

Design doc: https://www.notion.so/scrollzkp/Proposal-Interactive-mode-for-coordinator-and-prover-f4340330f37743ebab796c6e20f972b2

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

Deployment tag versioning

Has tag in common/version.go been updated?

• No, this PR doesn't involve a new deployment, git tag, docker image tag
• Yes

Breaking change label

Does this PR have the breaking-change label?

• No, this PR is not a breaking change
• Yes

[Thegaram]

Merging now so that we can deploy and test.