feat(rollup_sync_service): handle multiple batches in `FinalizeBatch` event

[amoylan2]

1. Purpose or design rationale of this PR

FinalizeBatch event will influence one or more batches

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
• [x] 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
• [x] Yes

4. Breaking change label

Does this PR have the breaking-change label?

• [x] This PR is not a breaking change
• [ ] Yes

[amoylan2]

LGTM. does this pr also need to bump version?

A reminder of features left (in other PRs):

1. codecv3 when calculating batch hashes after Darwin.
2. adding new unit tests after the contract and rollup-relayer are ready (fetching test cases by running a local testnet).

Let's open another pr to implement the changes related to codecv3

[colinlyguo]

the feature is not a full set of new features to be released. do we need to bump version as well? or move the related changes into an upgrade4 branch? cc @Thegaram @georgehao

[Thegaram]

the feature is not a full set of new features to be released. do we need to bump version as well? or move the related changes into an upgrade4 branch? cc @Thegaram @georgehao

So we will need one more PR to add codecv3, right?

I think we can merge it to develop (but make sure it's backward compatible). And let's bump version so that we can test this on our nodes first.