fix: make proof data handler backwards compatible

[Artemka374]

What ❔

Revert WS-related changes for proof data handler

Why ❔

Is this a breaking change?

• Yes
• No

Operational changes

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zkstack dev fmt and zkstack dev lint.

[Copilot]

Pull Request Overview

This PR reverts recent WS-related changes in the proof data handler to ensure backwards compatibility. Key changes include updating API endpoints to remove WS-specific logic, refactoring error handling to use a custom error type instead of generic anyhow errors, and removing obsolete middleware and configuration fields.

Reviewed Changes

Copilot reviewed 48 out of 48 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
core/node/proof_data_handler/src/request_processor.rs	Refactored API endpoints and error handling including panic removals
core/node/proof_data_handler/src/middleware.rs	Removed the metrics middleware
core/node/proof_data_handler/src/metrics.rs	Adjusted dependency import order
core/node/proof_data_handler/src/lib.rs	Updated server routing and endpoint definitions
core/node/proof_data_handler/src/errors.rs	Removed the NoContent variant from RequestProcessorError
core/node/node_framework/src/implementations/layers/proof_data_handler.rs	Modified wiring for the proof data handler task
core/lib/prover_interface/tests/job_serialization.rs	Adjusted serialization tests for SubmitProofRequest changes
core/lib/prover_interface/src/api.rs	Updated SubmitProofRequest and ProofGenerationDataResponse formats
core/lib/protobuf_config, core/lib/env_config, core/lib/config	Removed obsolete fields to support backwards compatibility

Comments suppressed due to low confidence (3)

core/node/proof_data_handler/src/request_processor.rs:144

• Using panic here prevents graceful error handling in production. Consider returning a proper error via the Result type instead of panicking.

.unwrap_or_else(|| panic!("Missing header for {}", l1_batch_number));

core/node/proof_data_handler/src/request_processor.rs:151

• Using panic for missing protocol version info may lead to unexpected server crashes. It would be preferable to return an error that can be handled gracefully.

.unwrap_or_else(|| { panic!("Missing l1 verifier info for protocol version {minor_version}") });

core/node/proof_data_handler/src/request_processor.rs:160

• The use of panic here in the batch header retrieval can cause abrupt termination. Consider replacing it with proper error handling to improve robustness.

.unwrap_or_else(|| panic!("Missing header for {}", l1_batch_number));

[EmilLuta]

Dumb question -- but will proto be fine with the changes we've made? I assume yes, but thought to double check.

Mostly revert otherwise. Approved.