🔥 Remove custom exception handling

[connormaglynn]

👀 Purpose

• In relation to 🔒 Security Assessment Before Private Beta Release operations-engineering#4057
• To remove the custom exception logic that could potentially leak sensitive information to clients

♻️ What's changed

• Removed custom exception handling which rendered a template, displaying GitHub Exceptions (which could potentially leak sensitive information)
• Removed unused template page
• Remove unused /error route
• Add type annotations to the error handlers to show that they will receive the full exception - which may contain sensitive information

📝 Notes

• It's better to favour generic handling over custom handling for the start of the application
  • if we run into exceptions, we should try to handle them for the client i.e. retry the request.
  • If we run into a situation where an exception is thrown and it'd be useful to provide context, we should curate content for users instead of displaying the exception. For example, if we run out of seats so the invitation can't be sent we may want to inform the user that "Unfortunately, the organisation is currently full - please raise your request manually or try again later"
• In regards to debugging these scenarios when users experience them - all exceptions will be recorded in Sentry where only Operations Engineering team have access and contain a full stack trace of the exception

[github-actions]

🦙 MegaLinter status: ❌ ERROR

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	4	0	0	0.73s
✅ PYTHON	flake8	4		0	0.43s
✅ PYTHON	isort	4	2	0	0.17s
❌ PYTHON	pylint	4		2	5.89s
✅ REPOSITORY	gitleaks	yes		no	0.44s
✅ REPOSITORY	trivy	yes		no	4.69s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by