Feat/ls count only

[ValentinTorassa]

Community Contribution License

All community contributions in this pull request are licensed to the project maintainers
under the terms of the Apache 2 license.
By creating this pull request I represent that I have the right to license the
contributions to the project maintainers under the Apache 2 license.

Description

This PR adds a --count-only flag to mc ls to print only the total number of entries found, without printing each object/dir line. This is useful for scripting and quick “how many things are here?” checks.

Additionally, it extracts the storage-class filter condition into a small helper (storageClassAllowed) and adds a unit test covering that logic.

Behavior with --count-only:

• No per-entry output is printed.
• A single integer count is printed to stdout at the end.
• Existing semantics remain unchanged (recursive listing, rewinds/versions listing behavior, storage-class filter, etc.).

Motivation and Context

When working with large buckets, mc ls output can be expensive and noisy if you only need a count (e.g., CI scripts, smoke checks, automation). --count-only enables efficient counting without formatting or printing each entry.

The storageClassAllowed helper keeps the listing logic clearer and makes the storage-class filter behavior directly unit-testable.

How to test this PR?

Unit tests

Run the new unit test:

go test ./cmd -run TestStorageClassAllowed -v

Run full suite:

go test ./...

Manual / functional checks

1. Build:

go build -o mc-dev .

2. Confirm help shows the new flag:

./mc-dev ls --help | grep -n "count-only"

3. Compare normal listing vs count-only:

./mc-dev ls play/somebucket/
./mc-dev ls --count-only play/somebucket/

4. With recursion:

./mc-dev ls --recursive --count-only play/somebucket/

5. With storage-class filter (should match existing behavior):

./mc-dev ls --storage-class GLACIER --count-only play/somebucket/

Expected: --count-only prints a single number, and no object lines.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [ X ] New feature (non-breaking change which adds functionality)
• [ X ] Optimization (provides speedup with no functional changes)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• Fixes a regression (If yes, please add commit-id or PR # here)
• [ X ] Unit tests added/updated
• [ X ] Internal documentation updated
• Create a documentation update request here