Correctly encode password in ServerSettingsModel

[rmunn]

The x-www-form-urlencoded MIME type says that we're URL-encoding the password, so we need to actually URL-encode the password if we want it to be handled correctly at the other end.

Fixes #324.

---

This change is 

[github-actions]

Test Results

       8 files  ±0     333 suites  ±0   2h 23m 2s ⏱️ -9s
   988 tests ±0     932 ✔️ ±0    56 💤 ±0  0 ❌ ±0 
3 145 runs  ±0  3 022 ✔️ ±0  123 💤 ±0  0 ❌ ±0 

Results for commit 225c299. ± Comparison against base commit 49493f8.

♻️ This comment has been updated with latest results.

[imnasnainaec]

Should https://github.com/sillsdev/chorus/blob/bug/password-encoding/CHANGELOG.md#fixed be updated?

[rmunn]

Testing this is proving a bit more difficult than anticipated. Because the buggy code is in ServerSettingsModel, which is only used in the "login" part of the Chorus GUI, the buggy code path is only used when logging into production Lexbox. However, when you try to set someone's password on Lexbox to something with & or + in it (there are only a few characters that trigger the bug), the frontend code doesn't allow you to do it. I can create a test user in my local dev instance of Lexbox (by temporarily disabling the frontend check that forbids those characters), but then to do S/R in FieldWorks I have to check the "Custom URL" checkbox and that won't go through the buggy codepath.

To test this, I'll need to create a test user on Lexbox, then edit their data by hand in Postgres to set their password (and salt) to the password and salt that were created for my test user in local dev. Which I'm running out of time to do today.

[rmunn]

I have now tested it and proven that it works. Using the characters & or + is now safe in passwords with this bugfix. I created a test account with the password a&b+c d and Chorus failed to log in with that password before the bugfix, but succeeded after I applied this bugfix PR to my local copy of LibChorus.dll. (I have since changed the password on that test account, so I'm not revealing any active credentials here).

Once we fix the GHA build issues (which I suspect are because ubuntu-latest has just been switched to ubuntu-24.04 which no longer offers Python 2 as an installable package), then this can be safely merged with confidence that it is tested and working.

[imnasnainaec]

Reviewed 1 of 1 files at r1, 1 of 1 files at r2, 2 of 2 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @rmunn)

[imnasnainaec]

Reviewed 1 of 1 files at r1, 1 of 1 files at r2, 2 of 2 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @rmunn)

I reviewed all the files, but I don't have permission in this repo to "approve".

[rmunn]

Note that I changed ubuntu-latest to ubuntu-22.04 in this PR so that the python2 package would be available (it was removed in ubuntu-24.04), as it's still needed for testing Mercurial 3.3 builds of Chorus. That change also needs a corresponding change to the repo's checks, which are currently waiting for a test report from "build-and-test (ubuntu-latest, net8.0)" when they should instead be waiting for "build-and-test (ubuntu-22.04, net8.0)". I don't have the repo permissions to make that particular change.

[rmunn]

@hahn-kev - Looks like it's not auto-merging until the required status has been reported green — and it won't be reported green, because the status is looking for ubuntu-latest but the test is now running on ubuntu-22.04 instead (because 24.04 removed python2, and our CI build still tries to install a python2 package).