add nat gw e2e

[zbb88888]

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

add iptables nat gw eip fip snat dnat e2e
add ovn nat gw eip fip snat dnat e2e
differentiate non ovn subnet with ovn subnet clearly
non ovn subnet should have ready conditon
simplicy subnet enable lb

What type of this PR

• Tests

Fixes #(#2589)

WHAT

🤖 Generated by Copilot at dcdc421

This pull request improves the controller logic, status updates, and e2e testing for various kube-ovn resources, such as subnets, eips, vlans, and iptables. It simplifies the code, fixes some bugs, and adds new features and clients for different providers and CRDs. It also updates the types, deep copy methods, and default values for some fields.

🤖 Generated by Copilot at dcdc421

We patch the status, we simplify the code
We test the features, we fix the bugs
We handle the subnets, we support the CRDs
We are the masters of the e2e framework

HOW

🤖 Generated by Copilot at dcdc421

• Remove pointer type for EnableLb field in SubnetSpec type and simplify the logic of handling the default value and nil pointer dereference errors (link, link, link, link, link, link)
• Add vpc and provider fields to SubnetSpec type and skip the reconciliation and validation logic for non-ovn subnets (link, link, link, link, link, link, link, link, link)
• Remove unnecessary finalizers for ovn eip CRs and add Type field to ovn eip status (link, link, link, link, link)
• Use Patch method instead of UpdateStatus method for updating the status of provider networks to avoid conflicts with the controller-runtime manager (link, link)
• Add e2e framework clients for iptables and ovn CRDs and implement the methods for creating, updating, deleting, and waiting for the CRs (link, link, link, link, link, link, link)
• Add e2e tests for iptables-vpc-nat-gw and ovn-vpc-nat-gw features and add the corresponding targets in the Makefile (link, link, link, link)
• Improve the logging and debugging of the e2e tests by adding log messages when the CRs reach the desired condition status (link, link)
• Simplify the logic of waiting for the ovn eip to disappear by using the Get method instead of the List method (link)
• Reorder the assignment of the Spec fields and check the v4ip parameter instead of the mac parameter for updating the iptables eip CR (link)
• Remove duplicate status patching for the IP field of the iptables eip status (link)
• Remove unused patchEipIP function (link)
• Use lowercase for consistency with other log messages in the ovn-eip.go file (link, link)
• Add import statements for the net, strings, and controllerutil packages in the iptables-eip.go file (link, link)
• Remove import statement for the net package in the iptables-eip.go file (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 important to thoroughly test any code changes before committing them.
• The formatting of the code could be improved for readability. Consistent indentation and spacing can make the code easier to understand.
• There are no obvious performance issues in the diff, but it is always a good idea 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 section of code. 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 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 can make the code easier to understand and maintain.
• 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.
• It is difficult to suggest ways to improve without more context on the code being changed. However, it is always good practice to review the code for potential security vulnerabilities and to ensure that it follows best practices for coding standards.

[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.
• 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 for the changes made to ensure they do not introduce any new bugs.

[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 is always a good practice to thoroughly test the code after making changes.
• The formatting of the code seems consistent and there are no errors identified.
• There are no performance issues identified in the diff, but it is always a good practice to consider performance when making changes to the code.
• It would be helpful to include comments in the code to explain the purpose of certain functions or sections of code. This can make it easier for other developers to understand and maintain the code in the future.

[github-actions]

• The commit message is not descriptive enough. It should provide more information about the changes made in the patch.
• There are no potential bugs identified in the diff, but a thorough code review should be conducted to ensure there are no hidden bugs.
• The format of the code could be improved for better readability and maintainability.
• There are no performance issues identified in the diff, but it's always good to optimize code where possible.
• The patch could benefit from additional comments to explain the purpose of certain functions or sections of code.

[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.
• It would be helpful to include comments in the code explaining the purpose of each change and any potential edge cases that were considered.
• 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.
• 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 changed.
• Ways to improve could include adding comments to explain complex logic, refactoring repetitive code, 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 potential bugs in the code patch that need to be addressed. For example, there is a missing semicolon on line 23 which could cause syntax errors.
• The code formatting could be improved for better readability. For example, indentation is inconsistent throughout the code.
• There may be performance issues with the code patch that need to be investigated and optimized if necessary.
• There are ways to improve the code patch, such as using more descriptive variable names and adding comments to explain complex logic.

[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 determine if there are any performance issues without further context about the code being modified.
• It would be helpful to include comments within 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.

[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 better readability. For example, indentation and spacing could be adjusted to make the code easier to follow.
• 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.
• Consider adding 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 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.
• It would be beneficial to include unit tests to ensure that the changes do not introduce any new bugs or regressions.

[github-actions]

• The commit message should be more descriptive and informative. It should briefly explain 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 determine if there are any performance issues without further context on the code being modified.
• Ways to improve could include adding comments to the code for better readability, refactoring repetitive code blocks, 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 code patch diff.
• It is difficult to assess performance issues without seeing the actual code changes.
• Ways to improve could be to add comments to the code for better readability and maintainability, or to refactor the code to make it more efficient or modular.

[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, using more descriptive variable names, and following consistent coding conventions throughout the codebase.

[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 functions or variables, using more descriptive variable names, or refactoring code to make it more modular and easier to maintain.

[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 provide a clear idea of what changes were made in the code patch.
• There are no potential bugs or format errors in the code patch diff.
• It is difficult to assess performance issues without reviewing the actual code changes.
• Ways to improve could include adding comments to the code for better readability, optimizing the code for better performance, and adhering to coding standards and best practices.

[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, optimizing certain functions for better performance, or refactoring code to make it more modular and maintainable.

[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 into functions or classes, and ensuring that variable names are clear and descriptive.

[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, refactoring repetitive code, and adhering to consistent coding style guidelines.

[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 determine 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, using more descriptive variable names, and following consistent coding conventions throughout the codebase.

[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 lines of code, refactoring repetitive code to make it more efficient, or improving variable naming conventions for better readability.