Mainly to make it easier to initialize the SERVICES global correctly in
more than one place.
Also this stuff really shouldn't live at the crate root anyway.
This way users can have a simpler time configuring this stuff and we can
worry about the spec compliance parts and specifying the same thing over
and over parts.
ReloadHandle is taken from conduwuit commit
8a5599adf9eafe9111f3d1597f8fb333b8b76849, authored by Benjamin.
Co-authored-by: Benjamin Lee <benjamin@computer.surgery>
The "listening for incoming traffic on ..." log line is new, but
something I've wanted even when we only supported one listener.
I considered getting rid of `clippy::too_many_lines` by factoring out
the construction of `app` to a separate function, but found that
specifying it's type (or relevant traits) got quite hairy.
This is a config compatibility break.
The ability to listen on multiple ports, including both TLS and non-TLS,
is necessary for running complement against grapevine.
This separates concerns a bit more. We will probably want to extend the
logic for config loading in the future, and that stuff should all live
in the relevant place. This change points us in the right direction.
This functionality was never actually used AFAICT, as no way to provide
alternate profiles was ever provided.
This changes the configuration format to remove the `[global]` section,
everything that was previously under that namespace is now at the top
level.
The configuration file is now the canonical way to, well, configure.
This change is desirable because it gives us much more flexibility with
how configuration is structured. Environment variables are insufficient
because, for example, they're a flat namespace and have no built-in way
to represent lists.
Unfortunately we need to pull tracing-opentelemetry from git because
there hasn't been a release including the dependency bump on the other
opentelemetry crates.
Also adds a utility for formatting an error message in addition to all
of its sources, i.e. errors that came before it that led to the current
error.
This helps us to provide better error messages to users by including
more information: both our own error message and all of the underlying
error messages, if any, instead of only one or the other.
`panic!()` (and things that invoke it, such as `expect` and `unwrap`)
produces terrible looking error messages and `std::process::exit()`
doesn't run destructors. Instead, we'll make a `try_main` that can
return a `Result` with a structured error type, but for now I'm going to
be lazy and just use `Box<dyn Error>`. Then, `main` will call it and
return the appropriate `ExitCode` value based on `try_main`'s `Result`.
This gives us the opportunity to produce good error messages and doesn't
violently terminate the program.
This allows us to use the `ruma_route` convenience function even when we
need to add our own hacks into the responses, thus making us less
reliant on Ruma.
This change is fully automated, except the `rustfmt.toml` changes and
a few clippy directives to allow specific functions with too many lines
because they are longer now.
