Implement OpenAPI Specification for Web API Endpoints

[lzjqsdd]

Issue Description

The current implementation of web API endpoints in router_handler.rs lacks standardized documentation and specification. This makes it difficult for API consumers to understand the available endpoints, expected request/response formats, and error handling.

Proposed Solution

Implement the OpenAPI Specification (OAS) for all REST API endpoints to provide a standardized, language-agnostic interface description.

Benefits of OpenAPI Specification

1. Standardized Documentation - OpenAPI provides a formal standard for describing HTTP APIs, making it easier for developers to understand how the API works 1 .
2. Improved Developer Experience - Developers can understand and interact with the service with minimal implementation logic.
3. Code Generation - Enables automatic code generation for clients and servers, reducing development time and errors.
4. Interactive Documentation - Generates interactive API documentation that allows testing API endpoints directly from the documentation.
5. Design-First Approach - Enables defining the API with types and examples before implementation, allowing for better API design.
6. Consistency - Ensures consistency in API design and documentation across the project
7. Tooling Ecosystem - Access to a wide range of tools for validation, testing, and documentation.

The following endpoints in router_handler.rs need OpenAPI documentation:

Router::new()
    .route("/metrics", get(metrics))
    .route("/report", get(report))
    .route("/api/overview", get(overview))
    .route("/api/config", get(|| async { Json(conf) }))
    .route("/api/browse", get(browse))
    .route("/api/block_locations", get(block_locations))
    .route("/api/workers", get(workers))
    .route("/add-dcm", get(add_dcm))
    .route("/get-dcm", get(get_dcm))
    .route("/remove-dcm", get(remove_dcm))
    .route("/workers", get(workers1))