Endpoint for skills on my progress

[barna-isaac]

This adds an endpoint to show skills on My Progress.

It's just the one app for now, and given how close the symposium is, the following are hardcoded:

• this only ever shows attempts from the Mental Maths Practice App. The UI is hardcoded to only show this (we don't have app discovery yet), but I thought it might be a privacy concern having the endpoint return more data than is visible to users on the UI. In the privacy policy, we tell users to expect their teachers seeing the contents of their My Progress page, so I thought it important that this data is indeed what's accessible to a teacher.
• for now, always shows results from the past year. In the future, these will probably be parameters, but I didn't want to introduce them just yet (it'd be extra work validating these)
• For now, this is not cached, but if @jsharkey13 thinks this would important, I can get it done quickly!
• Not a concern for now as there's just the one app, but I wondered if @jsharkey13 has a preference whether to always return results from all apps, or for the app to be a parameter and return results just for the requested app. The second is simpler, while the first might be more performant.

---

Pull Request Check List

• Unit Tests & Regression Tests Added (Optional)
• Removed Unnecessary Logs/System.Outs/Comments/TODOs
• Added enough Logging to monitor expected behaviour change
• Security - Injection - everything run by an interpreter (SQL, OS...) is either validated or escaped
• Security - Data Exposure - PII is not stored or sent unencrypted
• [] Security - Data Exposure - Test any altered or created endpoints using swagger
• Security - Access Control - Check authorisation on every new endpoint
• ~[ ] Security - New dependency - configured sensibly not relying on defaults
• ~[ ] Security - New dependency - Searched for any know vulnerabilities
• ~[ ] Security - New dependency - Signed up team to mailing list
• ~[ ] Security - New dependency - Added to dependency list
• ~[ ] DB schema changes - postgres-rutherford-create-script updated
• ~[ ] DB schema changes - upgrade script created matching create script
• ~[ ] Updated Release Procedure & Documentation (& Considered Implications to Previous Versions)
• Peer-Reviewed

[codecov]

Codecov Report

❌ Patch coverage is 84.21053% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.96%. Comparing base (d7e3726) to head (91a1665).

Files with missing lines	Patch %	Lines
.../java/uk/ac/cam/cl/dtg/isaac/api/SkillsFacade.java	81.81%	4 Missing ⚠️
...g/isaac/dao/PgSkillsAttemptPersistenceManager.java	85.71%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #808      +/-   ##
==========================================
+ Coverage   40.89%   40.96%   +0.07%     
==========================================
  Files         550      550              
  Lines       23504    23540      +36     
  Branches     2831     2834       +3     
==========================================
+ Hits         9611     9644      +33     
- Misses      13026    13027       +1     
- Partials      867      869       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jsharkey13]

This query is complex!

Why do we need the length verification of attempts? I thought each attempt was stored separately, and surely we don't store empty attempts since even sending them to the API would waste bandwidth, server resources and time?

[barna-isaac]

@jacbn has also raised this! #798 (comment). I wanted to record empty attempts because I wanted us to later have the option to be strict about also counting these. What the strict thing is depends will depend on the target. If it's something like "number of attempts", where the target is in the numerator, the strict thing to do is to drop these. If it's something like "percentage of correct attempts", where the total number is in the denominator, the strict thing to do is to keep these.

Are you worried about how this query might perform or whether the empty attempts will take up too much space in the database?

[barna-isaac]

@jsharkey13 and I have agreed to stop recording empty attempts. The Anvil app should stop sending these, and the API shouldn't allow any. Recording empty attempts is not an effective way to protect against a user that only wants to submit easy answers, as they could just refresh the page.

[barna-isaac]

We'll apply the suggested changes as a separate refactor.