Push most endpoint and extractor logic into functoins of `App`.

This is, again, groundwork for logic that requires more than just a database connection.

The login process has been changed to be more conventional, attempting login _before_ account creation rather than after it. This was not previously possible, because the data access methods used to perform these steps did not return enough information to carry out the workflow in that order. Separating storage from password validation and hashing forces the issue, and makes it clearer _at the App_ whether an account exists or not.

This does introduce the possibility of two racing inserts trying to lay claim to the same username. Transaction isolation should ensure that only one of them "wins," which is what you get before this change anyways.

1 files changed, 2 insertions, 2 deletions

diff --git a/.sqlx/query-c0b5b8401995ea7ae491946617e402396d761dc5c1d3ffde85e5f8fe6cce5a6b.json b/.sqlx/query-52aa7910b81c18c06673f57b7a8e81f7f317427b0c29b29d142bb50e4ef3c117.json
index 66aefac..83a6c90 100644
--- a/.sqlx/query-c0b5b8401995ea7ae491946617e402396d761dc5c1d3ffde85e5f8fe6cce5a6b.json
+++ b/.sqlx/query-52aa7910b81c18c06673f57b7a8e81f7f317427b0c29b29d142bb50e4ef3c117.json
@@ -1,6 +1,6 @@
 {
   "db_name": "SQLite",
-  "query": "\n                insert or fail\n                into login (id, name, password_hash)\n                values ($1, $2, $3)\n                returning id as \"id: Id\", name\n            ",
+  "query": "\n                insert or fail\n                into login (id, name, password_hash)\n                values ($1, $2, $3)\n                returning\n                    id as \"id: Id\",\n                    name\n            ",
   "describe": {
     "columns": [
       {
@@ -22,5 +22,5 @@
       false
     ]
   },
-  "hash": "c0b5b8401995ea7ae491946617e402396d761dc5c1d3ffde85e5f8fe6cce5a6b"
+  "hash": "52aa7910b81c18c06673f57b7a8e81f7f317427b0c29b29d142bb50e4ef3c117"
 }