Add route register functions for different HTTP methods with different kinds of access to state

[jbearer]

Also refactor higher order async functions and improve documentation.

commit 56dc3ab (HEAD -> feat/method-registers, origin/feat/method-registers)
Author: Jeb Bearer [email protected]
Date: Fri Jun 17 15:44:20 2022 -0700

Update route parsing to register routes based on `Route::patterns`.

A nice feature is that the new routing allows the route name to be
different from the first segment of the route. This lets us do RESTy
things like

GET /greeting
POST /greeting

being different routes (see the hello-world example).

Also implemented just enough of route parsing/request parsing to get
the example to work, although I expect this will be replaced soon.

commit 6a0cf94
Author: Jeb Bearer [email protected]
Date: Fri Jun 17 15:08:34 2022 -0700

Interfaces for specific HTTP methods with mutable or immutable access.

The main point of this change is to add methods (get, post, put, and
delete) that are slightly more typesafe than `at`, for registering
handlers for routes with specific HTTP methods. Instead of passing
the top-level state to the handlers for these routes, we treat the
state as something that acts like a RwLock, automatically acquire
the lock for reading or writing, depending on the method and then
pass either a &State or &mut State to the handler. This decreases
boilerplate and makes it harder to accidentally register a mutating
route handler for a pure route, like GET.

In addition, this is a pretty big refactor of the original interfaces
in order to clean up and settle on a pattern for dealing with async
functions and lifetimes.

* By using associated types to name or uniquely identify some types
  in function/trait bounds, I was able to eliminate a few phantom
  type parameters in some of the route types. This in turn stops
  "phantom constraints" from propagating all the way up the call
  stack, removing a few Send, Sync, and 'static requirements.
* I decoupled `State` from `RequestParams`, so route handlers now
  take two arguments. This makes the interfaces a bit more consistent
  between `at` (where the handler takes a `State` directly) and `get`,
  etc. (where the handler takes a `<State as ReadState>::State`.
* I ran into a Rust compiler bug which trips when we have Fn constraints
  that take a reference and return a future (which we do everywhere, now).
  There is a reasonable workaround that just requires a little bit more
  boxing. This should be thoroughly documented now.
* Improved documentation and expanded/added examples throughout.

[pictographer]

Wow. This is awesome.