Replace usage of RS256 JWT signing with simpler HS384

[spwoodcock]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

#1574
#1539

Describe this PR

• Initially I thought that RS256 would be the best encryption algorithm for us: it's the stronger choice and has some advantages.
• However I neglected to consider ease of use and deployment:
  • Uses need to generate a pub/priv key pair - while we can automate this a bit, it's not ideal.
  • Generated RSA keys are a bit of a pain to use in CI variables (they could be base64 encoded to get around this).
• The symmetric algo HS384 is absolutely fine and secure enough for our use case.
• I chose this over HS256 as a good middle ground of bit length and future proofing (overkill still).
• It's supported by pyjwt and electric-sql 👍
• We can re-use the ENCRYPTION_KEY variable we already have in FMTM for the database encryption 🎉

Note the ENCRYPTION_KEY is 42-bits and we ideally need a 48-bit secret for HS384, but it's not a huge dealbreaker.
We could add a migration in future to update the tokens to more bits if needed.

Review Guide

Try and sign in.

Checklist before requesting a review

• 📖 Read the FMTM Contributing Guide: https://github.com/hotosm/fmtm/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[spwoodcock]

Merging this early so I can test it with the mapper frontend / electric-sql.

Added @Sujanadh in review as a sanity check - let me know if any issues 👍