feat: add support for EIP QoS

[shane965]

1. Create a QoSPolicy CRD and manage its lifecycle.
2. Add a new "spec.qosPolicy" field to iptablesEIP to relate to the QoSPolicy.
3. Configure NATGW EIP QoS when "spec.qosPolicy" changes.
4. Implement NATGW EIP QoS functionality using Linux TC.

• Make sure you have followed Kube-OVN Code Style.

What type of this PR

• Features

Which issue(s) this PR fixes:

Fixes #2496

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why.
• There are no potential bugs or format errors in the diff.
• It is difficult to assess performance issues without further context on the codebase and the changes made.
• Ways to improve could include adding comments to explain complex logic, using more descriptive variable names, and following consistent coding style throughout the codebase.

[github-actions]

• The commit message should be more descriptive and informative. It should briefly explain what changes were made and why.
• There are no potential bugs or format errors in the diff.
• It is difficult to assess performance issues without more context about the code being changed.
• It would be helpful to include comments in the code explaining the purpose of each change and how it improves the code.
• It would be beneficial to include unit tests to ensure that the changes do not introduce new bugs or regressions.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why they were necessary.
• There are no potential bugs identified in the diff, but it is always important to thoroughly test any changes before committing them to ensure that they do not introduce new bugs or issues.
• The formatting of the code appears to be consistent and follows best practices, so no format errors have been identified.
• There are no obvious performance issues with the code patch, but it is always a good idea to consider potential performance impacts when making changes to code.
• It would be helpful to include comments in the code to explain what each section does and why it is necessary. This can make it easier for other developers to understand and maintain the code in the future.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why.
• There are no potential bugs identified in the diff, but it would be helpful to have some comments explaining the changes made for future reference.
• The formatting of the code could be improved for readability. For example, adding whitespace between operators and using consistent indentation.
• There are no performance issues identified in the diff, but it would be helpful to run some tests to ensure that the changes do not negatively impact performance.
• It would be helpful to include some unit tests to ensure that the changes made do not introduce new bugs or regressions.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why they were necessary.
• There are no potential bugs or format errors in the patch diff.
• It is difficult to assess performance issues without more context about the code being modified.
• Ways to improve could include adding comments to explain the purpose of certain sections of code, using more descriptive variable names, and following consistent coding conventions throughout the file.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why they were necessary.
• There are no potential bugs identified in the diff, but it would be helpful to have more context on the code being changed to ensure that there are no unintended consequences.
• The formatting of the code could be improved for readability. Consistent indentation and spacing should be used throughout the file.
• There are no performance issues identified in the diff, but it would be helpful to have more information on the expected performance impact of the changes.
• Consider adding comments to the code to explain the purpose of each function or block of code. This will make it easier for other developers to understand and maintain the code in the future.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why they were necessary.
• There are no potential bugs or format errors in the diff.
• It is difficult to assess performance issues without more context about the code being modified.
• It would be helpful to include comments in the code explaining the purpose of each change and how it improves the overall functionality.
• Consider adding unit tests to ensure that the changes do not introduce new bugs or regressions.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why they were necessary.
• There are no potential bugs identified in the diff, but a thorough testing of the code is recommended to ensure that there are no unintended consequences of the changes made.
• The formatting of the code could be improved for better readability. Consistent indentation and spacing should be used throughout the code.
• There are no performance issues identified in the diff, but it's always good practice to consider the impact of any changes on the overall performance of the system.
• The code patch diff could benefit from comments explaining the purpose and functionality of each section of code. This will make it easier for other developers to understand and maintain the code in the future.

[shane965]

@hongzhen-ma , could you review my code? Thank you!

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes were made and why.
• There are no potential bugs or format errors in the patch diff.
• It is difficult to assess performance issues without further context on the codebase and the changes made.
• Ways to improve could include adding comments to explain complex logic, using more descriptive variable names, and following consistent coding conventions throughout the codebase.