Add Count RPC to EndDevice registry

[happyRip]

Summary

References https://github.com/TheThingsIndustries/lorawan-stack/issues/4802

Changes

• Add Count RPC to EndDeviceRegistry with REST endpoint GET /applications/{id}/devices/count.
  • Reuses existing CountEndDevices store method; requires RIGHT_APPLICATION_DEVICES_READ.

Testing

Steps

1. Register an application with some end devices.
2. Call GET /applications/{app_id}/devices/count with valid auth. Verify response {"count": N}.
3. Call without RIGHT_APPLICATION_DEVICES_READ and verify permission denied.

Results

Read device count

$ curl -sk \
  -H "Authorization: Bearer $API_KEY" \
  'https://localhost:8885/api/v3/applications/count-test-app-1778171996/devices/count'

returns

{"count":2}%

Use an API key with no read permission

$ curl -sk \
  -H "Authorization: Bearer $API_KEY_NO_READ" \
  'https://localhost:8885/api/v3/applications/count-test-app-1778171996/devices/count'

returns

{
  "code": 7,
  "message": "error:pkg/auth/rights:insufficient_application_rights (insufficient rights for application `count-test-app-1778171996`)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/auth/rights",
      "name": "insufficient_application_rights",
      "message_format": "insufficient rights for application `{uid}`",
      "attributes": {
        "missing": [
          "RIGHT_APPLICATION_DEVICES_READ"
        ],
        "uid": "count-test-app-1778171996"
      },
      "correlation_id": "3f2697171ad7429bbccba2e878ce960c",
      "code": 7
    }
  ]
}

Regressions

Existing List and Delete device endpoints are unchanged. Store layer CountEndDevices was already tested.

Notes for Reviewers

The store interface and bunstore implementation for CountEndDevices already existed (used by deleteApplication/purgeApplication). This PR only adds the proto definition and gRPC handler to expose it as a public API.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[happyRip]

Imre is on leave (Stack Reviewers 1)

[johanstokking]

API and implementation look good but this is missing tests.

[nicholaspcr]

A few points:

• There should be a CHANGELOG entry
• Is it worth considering filters to this new endpoint?
  • created_since or other fields associated with IS device fields.

[nicholaspcr]

Why uint32 instead of uint64, considering that:

• The store implementation returns uint64
• The value we set in the total header (on any List requests) is derived from the uint64.

[nicholaspcr]

Add a unit test for this in the end_device_registry_test.go