feat: support dynamically changing qos for EIP

[shane965]

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

What type of this PR

Examples of user facing changes:

• Features

Which issue(s) this PR fixes:

Fixes #2633

WHAT

🤖 Generated by Copilot at 54e9570

This pull request adds support for multiple QoS policy rules with different actions and match criteria, and improves the QoS policy deep copy, validation, and reconciliation logic. It also updates the QoSPolicy CRD and the QoS policy functions for EIPs to use the new QoS policy spec fields and types.

🤖 Generated by Copilot at 54e9570

To manage the QoS policy rules
We added some types and some tools
With action and direction
And bandwidthLimit selection
We can handle more cases and use cases

HOW

🤖 Generated by Copilot at 54e9570

• Add new types and constants for QoS policy rules and modify QoSPolicySpec and QoSPolicyBandwidthLimitRule types to support multiple rules with different parameters and actions in pkg/apis/kubeovn/v1/types.go (link, link, link, link)
• Modify QoSPolicy, QoSPolicySpec, and QoSPolicyStatus types to deep copy the new fields in pkg/apis/kubeovn/v1/zz_generated.deepcopy.go (link, link, link)
• Modify QoSPolicy CRD schema and additionalPrinterColumns to reflect the new fields in yamls/crd.yaml (link, link, link)
• Add a function to compare QoS policy rules and return the added, deleted, and updated rules in pkg/controller/qos_policy.go (link)
• Modify QoS policy controller methods to handle different cases of QoS policy update, validate QoS policy rule names, and reconcile QoS policy rules for related EIPs in pkg/controller/qos_policy.go (link, link, link, link, link, link, link, link)
• Modify EIP QoS controller methods to apply or delete QoS policy rules based on the new fields and parameters in pkg/controller/vpc_nat_gw_eip.go (link, link, link, link, link)

[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 a good practice to thoroughly test the code after making changes to ensure that there are no unintended consequences.
• The formatting of the code looks consistent and correct.
• There are no obvious performance issues identified in the diff, but it is always important to consider the impact of any changes on the overall performance of the system.
• It would be helpful to include comments in 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.
• There are no potential bugs or format errors in the code patch diff.
• It is difficult to assess performance issues without seeing the actual code changes.
• Ways to improve could include adding comments to the code for better readability, refactoring repetitive code, and optimizing algorithms if applicable.

[shane965]

could you please review this pr? @bobz965 @hongzhen-ma

[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 more context about the code being changed.
• Ways to improve could include adding comments to explain complex logic, refactoring repetitive code, or optimizing algorithms for better efficiency.

[github-actions]

• The commit message should be more descriptive and informative. It should clearly state what changes have been made and why.
• There are no potential bugs or format errors in the code patch diff.
• It is difficult to assess performance issues without seeing the actual code changes.
• Ways to improve could include adding comments to the code for better readability, optimizing certain functions for better performance, or refactoring code to make it more modular and maintainable.

[oilbeater]

The yamls in chart should also be updated

[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 more context about the code being changed.
• Ways to improve could include adding comments to explain the purpose of certain sections of code, refactoring repetitive code to make it more concise, or optimizing algorithms for better performance.

[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.
• It would be helpful to include more comments in the code to explain the purpose of certain functions or sections of code.
• Consider adding unit tests to ensure that the changes made do not introduce new bugs or regressions.
• It may be beneficial to refactor some of the code to improve readability and maintainability.

[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 unclear if there are any performance issues without further context on the code being modified.
• Ways to improve could include adding comments to explain complex logic, refactoring repetitive code, or optimizing certain functions for better performance.

[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 more context about the code being changed.
• Ways to improve could include adding comments to explain the purpose of certain sections of code, refactoring repetitive code to make it more efficient, or improving variable naming conventions for better readability.