Restrict trigger push branch for GitHub Workflow

[apupier]

Note that I recreated a PR after this other one was closed I guess because the master branch was force pushed #5451

What is the purpose of the change

Feature branches rarely need their own CI runs: the code is already tested when a pull request is opened against a release branch. If the push trigger has no branch restriction and pull_request is also configured, every push to a branch with an open PR runs the workflow twice: once for the push and once for the PR synchronisation.

Always give the push trigger an explicit list of branches: this stops branches created from a release branch from inheriting its workflow runs.

see https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=430408443#GitHubActionsRecommendedPractices-Restrictthepushtriggertospecificbranches

For all Apache projects, there is a limited pool of GitHub action runners avilable at the same time (900).
This limit is regularly hit in the last months. (and currently hit at the time of writing this message)
it is causing new GitHub workflows to be queued, delaying the final results. i tis impacting all Apache projects using GitHub Workflows.

The goal of this PR is to reduce the load by cutting completely redundant GitHub Workflows build.

Related issues/PRs

Related issues: close #590 close #591
Related pr:#591

Brief change log

• Define the core abstraction and interfaces of the EngineConn Factory;
• Define the core abstraction and interfaces of Executor Manager.

Checklist

• I have read the Contributing Guidelines on pull requests.
• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
• If this is a code change: I have written unit tests to fully verify the new behavior.