Code of Conduct

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

Search before asking

• I had searched in the issues and found no similar issues.

Describe the proposal

This issue has two proposal:

1. move all parameter that user can adjust to a single class, connector use XXXSourceConfig/ XXXSourceOptions.
   Update EnvCommandOptions to describe the parameters we can adjust in config env part.
   Update ServerConfigOptions to describe the parameters we can adjust about Zeta Engine config (config in SeaTunnel.yaml).

The benefits:

• We can easily know what parameter can be adjusted, that can help us to tune the performance.
• When version release, we can easily know which parameter has been changed, which can break the user version upgrade, which is added in new version, So we can record this into version upgrade document (although we don't have it yet).

2. refactor connector, implement TableSourceFactory, TableSinkFactory interface and implement createSource, createSink, optionRule method.

In optionRule method, describe which parameter is necessary, which is optional, which are the conflicts with other parameter. (need action1 done)

Move the connector creation logic from Connector to ConnectorFactory.

The benefits:

• Know the relationship between parameters. Use the optionRule check the config before create connector instance.
• This can be used in SeaTunnelWeb.

Welcome to do this with me

Task list

What should a Pull Request accomplish?

• List and describe the connector parameters in the Factory.optionRule() method.
  While doing so, we can move all parameters into the XXXXOptions class to unify the code style and centralize the parameters into a single file.

• Move the connector creation logic into Factory.createSource/createSink.
  Implement the createSource/createSink methods in Factory and instantiate the corresponding connector.

Are you willing to submit PR?

• Yes I am willing to submit a PR!