fix(quota): prefill quota update with a limit the form accepts

[Somilg11]

Description

harbor quota update prefilled the interactive form with a storage limit its own validator rejects, so confirming an unchanged form always errored out.

The default came from BytesToStorageString, which formats the limit as "%.1f GiB" / "%.2f MiB", while the "Quota Limit" input validates with strconv.ParseInt. ParseInt("50.0") fails, so the user had to clear the field and retype the number, for every possible limit, not just some.

The same line also reported an unlimited quota (hard["storage"] == -1) as current storage: -0.00 MiB, even though the quota list view already renders -1 as Unlimited.

• Fixes [bug]: quota update prefills a storage limit its own form rejects #1096

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation update
• Chore / maintenance

Changes

• Add storageDefaults, which converts the hard limit in bytes into a whole number plus the largest unit that divides it evenly, so the prefilled default is a value the form accepts and an untouched form round-trips back to the limit it was seeded with.
• Return an empty value for a limit that cannot be expressed as a whole number of MiB/GiB/TiB, including an unlimited quota, so the user is asked for a value instead of being handed one the form rejects.
• Add currentStorage, so -1 is reported as Unlimited and matches the quota list view.
• Drop the unchecked storagearr[1] index and the string splitting it belonged to, along with the now-unused slices and strings imports.
• Add a trailing newline to the current storage: message, which previously ran into the form.
• Add unit tests for both helpers, covering the whole-unit conversions, the round-trip through utils.StorageStringToBytes, the unlimited case and the sub-MiB case.

Verification

gofmt -s, go vet ./..., go build ./... and go test ./... are clean.

Reproduced against a local stub returning two quotas — one with a 50 GiB hard limit, one unlimited — using binaries built from main and from this branch.

Before

harbor quota update 1 — the prefilled 50.0 is rejected by the form's own validator. The current storage: line is missing because it had no trailing newline and the form redraw overwrote it:

harbor quota update 2 — an unlimited quota prefills the limit as -0.00 and selects MiB. The current storage: -0.00 MiB line above it is again overwritten by the form:

After

harbor quota update 1 — the prefilled 50 is accepted, so confirming an unchanged form is a no-op:

harbor quota update 2 — the unlimited quota reads correctly and no invalid value is prefilled:

Notes

The unit selected by storageDefaults is the largest one that divides the limit evenly, so a 1536 MiB limit prefills as 1536 MiB rather than a fractional 1.5 GiB that the input would reject. utils.StorageStringToBytes only accepts ^(\d+)(MiB|GiB|TiB)$, so this keeps the value the view returns parseable by its caller.