Collect Statistics on SDK Usage via User-Agent Header

### Background

We aim to collect statistics on the number of requests to the consensus node from different SDKs and their versions. This can be achieved without modifying any protobuf messages by leveraging the user-agent header in gRPC requests.

# Proposed Implementation:
- **Metrics:**
- Track requests for each known SDK and its version.
- Include an "unspecified" metric for requests with no user-agent header.
- Include an "unknown" metric for requests with a user-agent header that doesn’t match a recognized SDK.
- **Handling Unknown User-Agents:**
- Do not log unknown user-agent headers at default logging levels to avoid security risks.
- Provide an option to enable logging dynamically for a limited time to analyze unknown user-agents, sanitizing data and limiting string length (e.g., 256 characters).
- **Managing Version Metrics:**
- To prevent metric explosion from random version strings, categorize SDK versions into ranges:
- Number of SDKs with versions older than a designated "old" version.
- Number of SDKs with versions between "old" and "latest."
- Number of SDKs with versions newer than "latest."
- Periodically update "old" and "latest" thresholds as new SDK versions are released, either manually or via automation.

**Additional Considerations:**
- **Performance:** Ensure parsing user-agent strings doesn’t degrade performance under high load. Optimize parsing logic or use sampling if needed.
- **Spoofing:** Note that attackers could spoof known SDK user-agents, skewing statistics, though this is likely an acceptable risk for informational metrics.
- **SDK Types:** If multiple SDK types exist (e.g., by language or platform), consider tracking them separately for richer insights.
- **Privacy:** Verify that collecting user-agent data aligns with privacy policies, though user-agents typically lack personal information.

### Acceptance Criteria

1. Capture information on SDK usage
2. No changes to protobuf objects
3. User cannot cause excessive logging or excessive metrics based on user-agent string
4. Dashboards for viewing SDK stats

### Dependencies

_No response_

### Definition of Ready (DoR) Checklist

- [ ] Clear acceptance criteria
- [ ] Clear and detailed description
- [ ] Dependencies identified
- [ ] Links to documentation
- [ ] Should be completable in 2-3 Days
- [ ] Initial draft of Low-level design document
- [ ] At least high level test plan
- [ ] Groomed/Estimated

### Definition of Done (DoD) Checklist

- [ ] Acceptance Criteria complete
- [ ] No Codacy issues greater than minor (in new code)
- [ ] JavaDocs updated/created
- [ ] Code commented
- [ ] Unit tests created/updated
- [ ] 80% test code coverage (in new code)
- [ ] Happy Path and major negative cases in HAPI tests as applicable