Adds error handling for badly formed UUIDs sent to API endpoints

[rtibbles]

Summary

• Uses django_filters filtering where possible for filtering by UUID fields
• Adds default UUIDFilter for morango UUIDField
• Handles ValueErrors arising during database queries to return the appropriate response that isn't a 500

References

Fixes #10999 - actual Sentry reports includes multiple endpoints, all of which should be addressed here (some of which are addressed by previous work).

Reviewer guidance

Where needed I have added additional test coverage, but most of this is just defensive programming.

---

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Critical and brittle code paths are covered by unit tests

PR process

• PR has the correct target branch and milestone
• PR has 'needs review' or 'work-in-progress' label
• If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• If this is an important user-facing change, PR or related issue has a 'changelog' label
• If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.16.0a21.dev0_git.7.g3a62e83a.pex
Windows Installer (EXE)	kolibri-0.16.0a21.dev0+git.7.g3a62e83a-unsigned.exe
Debian Package	kolibri_0.16.0a21.dev0+git.7.g3a62e83a-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.16.0a21.dev0+git.7.g3a62e83a-0.3.0.dmg
TAR file	kolibri-0.16.0a21.dev0+git.7.g3a62e83a.tar.gz
WHL file	kolibri-0.16.0a21.dev0+git.7.g3a62e83a-py2.py3-none-any.whl

[jredrejo]

Code is fine, some parts not easy to understand for me as they're clearly a special and smart use of the Django features. Added tests are pretty clear though.
I see no problems in the code and everything went well in my tests. I haven't tested in Postgresql where UUID format is a bit different but I trust Django folks have kept that in mind.

[jredrejo]

I didn't know about the existence of FILTER_DEFAULTS nor I could find it in the documentation https://django-filter.readthedocs.io/
I only have found some references in the django-filter forums to underestand how it worked. Looking at the code makes sense, and also, if I understand it correctly the place in the code where you added it forces it to be active during the execution of the whole django request. is that interpretation correct?

[rtibbles]

Yes - it does not appear to be documented, which is unfortunate, but it seemed to be the only way to set this global mapping from Field type to Filter class.

The other alternative would be to subclass FilterSet and then systematically use that for all our FilterSets (although, this would not work for automatically generated FilterSets using DRF's magic: https://www.django-rest-framework.org/api-guide/filtering/#djangofilterbackend as there doesn't seem to be a setting to set the default FilterSet class).

Setting it here seems to be early enough in the Django initialization sequence that it is now set for any derived class - because of the import path from morango, it needs to happen after Django app initialization, because of access to the models module.