Adds a 'sticky' column to threads and rewrites the thread index to
take sticky markings into account when ordering threads.
Stickies are not yet highlighted in any way in the forum overview.
This is a simplification over the previous approach. The OP of a
thread is just a normal post like any other in this model, which
allows some code simplifications (and future query convenience).
This took me some time to figure out so it's useful to document in the
commit message.
When chaining messages from actors, the result type of a message (i.e.
the actual `<M as Message>::Result`) is sometimes itself a
`Result<T, E>`.
In many cases this leads to a situation where the return type of a
message sending process is something like (simplified):
Future<Item=Result<Foo, ConverseError>, Error=actix::MailboxError>
Due to the implementation of
`From<actix::MailboxError> for ConverseError` it is possible to use
`.from_err()` on these futures to convert the future's `Error` to
`ConverseError`.
The type `Result` apparently implements `IntoFuture`, which means that
due to some trait magic that's been applied somewhere in the futures
API a call to `flatten()` can "lift" the contained error if the error
types match and give us a "simple"
Future<Item=Foo, Error=ConverseError>
From that point on chaining becomes easy.
Implements a new thread rendering pipeline which all posts and the
main thread body are first converted to a `RenderablePost` structure.
During the conversion to this structure, the post body is rendered as
Markdown and the author's email address is converted into the format
required by Gravatar.
This currently breaks error handling in page render flows. To fix it
properly, the database actor should return failable futures instead of
`Result<T>` wrapped in a future.
Implements an actor that can perform OAuth2 logins (not really
OIDC-compliant yet because Rust doesn't have an easy to use JWT
library that supports JWKS, and I don't have time for that right now).
Currently this hardcodes some Office365-specific stuff.
Adds columns for author names and emails to both threads and posts.
"Users" don't (yet? who knows!) exist as independent entity in
Converse, they are simply "inferred" via OIDC providers.