[Umbrella][Manager] Unify the InlongGroup workflow

[healchow]

Describe the proposal

Unify the InlongGroup workflow.

Combining the processes of Lightweight and Standard together, most of the processing logic can be reused.

For processes that need to distinguish between Lightweight and Standard, the configuration of InlongGroup can be used to distinguish them.

[Benefit]

1. Improve code reusability, thereby reducing maintenance costs.

2. Simplify the processing logic of various Listeners - the workflow only needs to be dispatched to the relevant processing Listeners, and the specific execution logic is handed over to the specific executor of this Listener to execute.

   For example, to create a Listener of a sink resource, you only need to hold the factory of the implementation class that creates the sink resource. At runtime, the instance is obtained according to the specific type, and the creation process can be implemented by it (such as the Hive library table).
   Otherwise, each type of Sink must implement a Listener…

3. Improve scalability: When other users use this process, they only need to implement the interfaces in the above factories, and they can expand the intranet process without changing the source code of Inlong-Manager.

Task list

• [Improve][Manager] Use SortConfigListener replace the LightGroupSortListener #5030
• [Improve][Manager] Remove the LightGroup-related workflow listener and definitions #5066
• [Improve][Manager] Handle the lightweight and standard inlong groups differently in workflow #5148
• [Bug][Manager] Failed to build Sort config as the relations is empty #5157
• [Feature][Manager] Merge the Selector classes into their related Listeners #5212

InLong Component

InLong Manager

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[healchow]

All sub-issues were resolved.