[cherry-pick-1.1-dev] fix load data stmt affect rows count calculation incorrectly

[noorall]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #https://github.com/matrixorigin/MO-Cloud/issues/2772

What this PR does / why we need it:

fix load data stmt affect rows count calculation incorrectly

[matrix-meow]

@noorall Thanks for your contributions!

Pull Request Review:

Title:

The title of the pull request is clear and concise, indicating that the PR is related to fixing an issue with the calculation of affected rows in the load data statement.

Body:

The body of the pull request provides relevant information about the type of PR (BUG), the specific issue it fixes, and why the PR is needed. It references the related GitHub issue for context.

Changes:

1. In mergeblock_test.go:

   • Added AddAffectedRows: true to two test cases.

2. In types.go:

   • Added a new boolean field AddAffectedRows to the Argument struct.
   • Modified the Split function to conditionally update arg.affectedRows based on the value of AddAffectedRows.

3. In compile.go:

   • Added AddAffectedRows field to the Argument struct when compiling the plan scope.

Feedback and Suggestions:

1. Code Optimization:

   • Instead of adding a new boolean field AddAffectedRows to the Argument struct, consider using a default value or refactoring the logic to avoid the need for this additional field. This can help simplify the code and reduce complexity.

2. Conditional Logic:

   • The conditional checks in the Split function could be consolidated to improve readability. Consider refactoring the logic to make it more concise and easier to follow.

3. Consistency:

   • Ensure consistency in variable naming and coding style across the changes made in different files to maintain code readability and maintainability.

4. Security Concern:

   • When introducing conditional logic based on the AddAffectedRows flag, ensure that this does not introduce any vulnerabilities related to data integrity or unexpected behavior. Perform thorough testing to validate the changes.

5. Documentation:

   • Consider adding comments or updating existing documentation to explain the purpose of the AddAffectedRows field and its impact on the affected rows calculation for better code understanding.

6. Testing:

   • Verify that the changes do not introduce regressions and that the affected rows calculation is accurate in all scenarios, including edge cases.

7. Review and Approval:

   • Request a review from a team member to validate the changes and ensure they align with the project's coding standards and best practices.

By addressing the optimization suggestions and ensuring the security implications are considered, the pull request can be enhanced for better code quality and maintainability.