feat: support form array in three notations

[kevwan]

Supports three array parameter notations:

1. Standard notation: /api?names=alice&names=bob
2. Comma notation: /api?names=alice,bob
3. Bracket notation: /api?names[]=alice&names[]=bob

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.57%. Comparing base (8690859) to head (346c71b).
Report is 189 commits behind head on master.

Additional details and impacted files

Files with missing lines	Coverage Δ
core/mapping/unmarshaler.go	96.23% <100.00%> (-0.25%)	⬇️
rest/httpx/util.go	100.00% <100.00%> (ø)

... and 5 files with indirect coverage changes

[kevwan]

The changes appear to be focused on improving the handling of array-type parameters in form values and some refactoring of the unmarshaler code. Let me break down the key changes:

1. Array Parameter Enhancement (rest/httpx/util.go):

• Added support for different array notation formats in form values:
  • Standard notation: ?names=alice&names=bob
  • Comma notation: ?names=alice,bob
  • Bracket notation: ?names[]=alice&names[]=bob
• Improved handling of array suffixes by removing [] from parameter names
• Removed unnecessary length check for values before appending to filtered slice

2. Unmarshaler Changes (core/mapping/unmarshaler.go):

• Added new constant comma = ","
• Added stringSliceType variable for type comparison
• Refactored code structure by moving functions around for better organization
• Added new helper function makeStringSlice to handle comma-separated string arrays
• Improved struct element filling with new fillStructElement function
• Enhanced type handling and pointer dereferencing

Positive Aspects:

1. Improved flexibility in handling array parameters with multiple notation support
2. Better code organization through refactoring
3. Added proper support for comma-separated string arrays
4. More consistent handling of pointer and non-pointer types
5. Better error handling and type checking

Suggestions for Improvement:

1. In GetFormValues, consider adding documentation for the empty value handling behavior since the length check if len(v) > 0 was removed
2. In makeStringSlice, consider adding error handling or logging for edge cases
3. Consider adding tests to cover the new array notation formats
4. The makeStringSlice function could benefit from a comment explaining its purpose and behavior
5. Consider adding validation for malformed array parameters in the bracket notation

Questions:

1. Was performance testing done for the new array handling methods, especially for large form submissions?
2. Are there any backward compatibility concerns with removing the empty value check in GetFormValues?

Security Considerations:

1. The code appears to handle input safely, but it might be worth adding input validation for array parameters to prevent potential DoS attacks through extremely large arrays

Overall Assessment:
The changes appear to be well-structured and improve the functionality of form parameter handling while maintaining code quality. The refactoring makes the code more maintainable and the new array handling features add valuable functionality.

[kevwan]

Fixed security considerations.