Feature/connection-pool-monitor frontend

[Oscarcheng0312]

• [x] I have read the CONTRIBUTING.md guidelines.
• [x] I have registered the PR changes.

Note: This is a Draft PR to collect early feedback on the UI and structure.
The data source can be switched between backend API and mock via a simple flag.

---

Ⅰ. Describe what this PR did

This PR adds a standalone frontend module for Connection Pool Monitoring (CPM) located under
console/src/main/resources/static/cpm.

Main Features

• Metrics overview (active/idle connections, waiting threads, execution counts)
• Table with expandable per-service details
• Druid & HikariCP specific metric panels (charts)
• Inline configuration editor dialog
• i18n (language toggle) and filter/search bar
• Pluggable data source: supports both backend endpoints and built-in mock data (for local demo)

This module is self-contained and does not modify the existing console-fe.
Currently, data are based on mockData.ts, and backend API integration will be implemented once ConnectionPoolController endpoints are finalized.
This PR is temporarily a draft for mentor review and will later be rebased onto 2.x for the official merge.

---

Ⅱ. Does this pull request fix one issue?

No specific issue is fixed.
This is part of the GSoC 2025 project: Connection Pool Monitoring and Configuration Framework (Seata AT/XA modes).

---

Ⅲ. Why are there no test cases (unit/integration)?

This PR only adds frontend static resources (React + TypeScript).
It does not include Java modules or backend logic that require test coverage.
Frontend UI tests and API integration tests will be added in a follow-up PR once backend endpoints are finalized.

---

Ⅳ. How to verify it

A) Use Backend API (recommended once endpoints are available)

1. Ensure the console exposes CPM endpoints such as:

   GET /api/v1/connection-pools/metrics
   GET /api/v1/connection-pools/configs
   PUT /api/v1/connection-pools/{serviceName}/config
   

2. In console/src/main/resources/static/cpm/src/services/api.ts, set:

   const USE_MOCK_DATA = false;
   

3. Build and run:

   cd console/src/main/resources/static/cpm
   npm ci
   npm run build
   
   # In another terminal
   mvn -DskipTests -pl :seata-console -am spring-boot:run
   

4. Open http://localhost:7091/cpm/ and verify:
   • Metrics grid and table render real data
   • Expanded rows show Druid/Hikari charts
   • “Edit Config” works (submit + refresh)

---

B) Use Mock Data (for local demo)

1. In src/services/api.ts, set:

   const USE_MOCK_DATA = true;
   

2. Build & run as above, then open http://localhost:7091/cpm/.
   Mock data will populate the metrics, tables, and charts for UI review.

---

Ⅴ. Special notes for reviewers

• ASF headers added to .ts, .tsx, .css, .html, and .md files.
  Headers are omitted for manifest.json, package.json, package-lock.json, and image assets.
• The CPM module uses Ant Design v4, TypeScript, and React, and is fully isolated under /static/cpm.
• No modifications were made to the existing console-fe.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 70.91%. Comparing base (78c275e) to head (045ef51).

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7692      +/-   ##
============================================
- Coverage     70.95%   70.91%   -0.04%     
  Complexity      992      992              
============================================
  Files          1322     1322              
  Lines         50322    50322              
  Branches       5946     5946              
============================================
- Hits          35705    35688      -17     
- Misses        11670    11687      +17     
  Partials       2947     2947              

see 14 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.