Specify the minimum required Rust version in the manifest

See merge request famedly/conduit!91

Also mention it in the deployment guide.

fix: also return successful PDUs in /send/:txnId

See merge request famedly/conduit!90

fix: state resolution bugs

See merge request famedly/conduit!89

Fix redacted_because field being sent as a string

Closes #87

See merge request famedly/conduit!88

Fix docker-compose trusted_servers env var

See merge request famedly/conduit!87

fix: logs for ruma crate

See merge request famedly/conduit!86

feat: forward federation errors to the client

See merge request famedly/conduit!85

fix: Forbidden instead of InvalidParam when joining

See merge request famedly/conduit!84

Update Dockerfile and docker-compose

See merge request famedly/conduit!39

And mention that an empty string can be used to configure
Conduit purely with env vars.

Mention the need for a config.

- Dockerfile now tracks the gitlab repository and the master branch.
- docker-compose now points to conduit.toml instead of Rocket.toml and
its env vars were also renamed from ROCKET_ to CONDUIT_.
Furthermore vectorim/riot-web was changed to vectorim/element-web

docs: APPSERVICES setup guide

See merge request famedly/conduit!83

fix: too many syncs

See merge request famedly/conduit!82

Update cargo-deb packaging for recent changes

See merge request famedly/conduit!61

improvement: federation get_keys and optimize signingkey storage

See merge request famedly/conduit!81

- get encryption keys over federation
- optimize signing key storage
- rate limit parsing of bad events
- rate limit signature fetching
- dependency bumps

I'm a bit torn on the "auth check based on the current state of the
room". It can mean multiple things:

1. The state of the room before the homeserver looked at the event at
all. But that means if a message event from a user arrives, but we
didn't see their join event before, we soft fail the message (even
though we would find the join event when going through the auth events
of the event and doing state res)

2. The state of the room after doing state-res with the event and our
previous room state. We need to do this state resolution to find the new
room state anyway, so we could just use the new room state for the auth
check. The problem is that if the incoming event is a membership leave
event, the new room state does not allow another leave event. This is
obviously the wrong option.

3. The state of the room after doing state-res with the state **before**
the event and our previous room state. This will mean a lot more
calculations because we have to run state-res again

We used 2. before and now use 1. again