ospfd: accept value with no maximum-paths

[chiragshah6]

Allow no maximum-paths to accept an optional value.
Reset the setting only when the value matches the configured maximum paths.
Use DEFPY to handle the optional argument.

Testing:
Before:
mlx-4600-05(config)# router ospf
mlx-4600-05(config-router)# no maximum-paths 13
% Unknown command: no maximum-paths 13

After:
mlx-4600-05(config)# router ospf
mlx-4600-05(config-router)# no maximum-paths 13
mlx-4600-05(config-router)#

[greptile-apps]

Hard-coded no-form range

When FRR is built with MULTIPATH_NUM above 128, the positive command accepts configured values above 128 but this no-form rejects those same values as unknown commands, preventing value-bearing removal of a valid configuration.

Prompt To Fix With AI

This is a comment left during a code review.
Path: ospfd/ospf_vty.c
Line: 2942

Comment:
**Hard-coded no-form range**

When FRR is built with `MULTIPATH_NUM` above 128, the positive command accepts configured values above 128 but this no-form rejects those same values as unknown commands, preventing value-bearing removal of a valid configuration.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Greptile Summary

This PR extends OSPF's no maximum-paths command with an optional value.

• Converts the no-form from DEFUN to DEFPY.
• Resets the setting only when the optional value matches the configured maximum.
• Continues to reset an unqualified no maximum-paths command to the build-time default.

Confidence Score: 4/5

The parser range mismatch should be fixed before merging because supported builds can configure values that the new value-bearing no-form cannot remove.

The positive command accepts values up to the configurable MULTIPATH_NUM, while the changed no-form rejects every value above 128 before its matching logic can run.

Files Needing Attention: ospfd/ospf_vty.c

Important Files Changed

Filename	Overview
ospfd/ospf_vty.c	Adds value-sensitive removal semantics, but the new hard-coded parser range is narrower than the supported build-dependent range.

Prompt To Fix All With AI

### Issue 1
ospfd/ospf_vty.c:2942
**Hard-coded no-form range**

When FRR is built with `MULTIPATH_NUM` above 128, the positive command accepts configured values above 128 but this no-form rejects those same values as unknown commands, preventing value-bearing removal of a valid configuration.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "ospfd: accept value with no maximum-path..." | Re-trigger Greptile}