[improve](information schema) introduce routine load job system table (#48963)

[sollhui]

pick #48963

Part IV of #48511

doc apache/doris-website#2196

Introduce routine load job statistic system table:

mysql> show create table information_schema.routine_load_job\G
*************************** 1. row ***************************
Table: routine_load_job
Create Table: CREATE TABLE `routine_load_job` (
`JOB_ID` text NULL,
`JOB_NAME` text NULL,
`CREATE_TIME` text NULL,
`PAUSE_TIME` text NULL,
`END_TIME` text NULL,
`DB_NAME` text NULL,
`TABLE_NAME` text NULL,
`STATE` text NULL,
`CURRENT_TASK_NUM` text NULL,
`JOB_PROPERTIES` text NULL,
`DATA_SOURCE_PROPERTIES` text NULL,
`CUSTOM_PROPERTIES` text NULL,
`STATISTIC` text NULL,
`PROGRESS` text NULL,
`LAG` text NULL,
`REASON_OF_STATE_CHANGED` text NULL,
`ERROR_LOG_URLS` text NULL,
`USER_NAME` text NULL,
`CURRENT_ABORT_TASK_NUM` int NULL,
`IS_ABNORMAL_PAUSE` boolean NULL
) ENGINE=SCHEMA;
1 row in set (0.00 sec)

There are some benefits to empower job with SQL query capability for statistical information:

• It can be used in conjunction with metrics add through [improve](routine load) add more metrics to observe the routine load job #48209 to roughly locate abnormal jobs when Grafana alarms, and the following SQL can be used:

SELECT JOB_NAME
FROM information_schema.routine_load_job_statistics
WHERE CURRENT_ABORT_TASK_NUM > 0
OR IS_ABNORMAL_PAUSE = TRUE;

• User can use the select * from information_schema.routine_load_job instead of the show routine load. The advantage is that the show routine load can only be searched by name, but SQL can be very flexible in locating jobs

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[sollhui]

run buildall

[doris-robot]

BE UT Coverage Report

Increment line coverage 0.00% (0/130) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	37.37% (9846/26350)
Line Coverage	29.05% (82459/283883)
Region Coverage	27.66% (42307/152969)
Branch Coverage	24.40% (21538/88254)

[sollhui]

run buildall

[hello-stephen]

BE UT Coverage Report

Increment line coverage 0.00% (0/130) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	37.38% (9850/26350)
Line Coverage	29.08% (82562/283910)
Region Coverage	27.67% (42334/152984)
Branch Coverage	24.41% (21548/88266)

[sollhui]

run buildall

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.

[hello-stephen]

BE UT Coverage Report

Increment line coverage 0.00% (0/130) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	38.85% (10275/26447)
Line Coverage	29.90% (85370/285495)
Region Coverage	28.54% (44003/154162)
Branch Coverage	25.26% (22508/89088)

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 0.00% (0/130) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	60.94% (15879/26057)
Line Coverage	53.16% (150824/283702)
Region Coverage	50.78% (91139/179487)
Branch Coverage	44.64% (44974/100750)

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 0.00% (0/130) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	60.94% (15879/26057)
Line Coverage	53.16% (150824/283702)
Region Coverage	50.78% (91139/179487)
Branch Coverage	44.64% (44974/100750)