Increase verbosity of debug info

[codesections]

This PR adds significantly more debug information at the RUST_LOG=warn level. (Semantically, the info added here is more appropriate at the RUST_LOG=info level – it provides info about normal functioning, not a warning of something unusual. But info logging contains a lot of other messages and I don't want these to get lost. Once we've debugged the current issues, I plan to downgrade these to info).

Specifically, this adds one type of logging and makes another more verbose:

1. Flodgatt now logs an event every time it sends an update to a user; the log notes the content of the toot, the timeline it came from, and the recipient's email & user id. Hopefully, this will allow us to debug the issue of certain messages not appearing on the local timeline in Firefox containers.
2. Flodgatt provides timeline/user information when logging errors that occur in sending messages. Hopefully this will allow us to determine whether the WARN flodgatt::redis_to_client_stream > WebSocket protocol error: Connection reset without closing handshake errors are cause by clients disconnecting without closing the connection or are due to a bug in our connection code. If the latter, then it is not an error at all – we should be closing the connection when clients disconnect, and the solution is simply to not log the error. If that's not the case, then we have some other work to do.

Two notes on this PR. First, this level of logging will clearly be excessive when run in production (it logs an event every time any user gets an update). This level of logging is likely high enough printing it to the console could be a significant bottleneck. Accordingly, I don't recommend running for long with this level of logging – just for long enough to get initial results and, hopefully, enough info to resolve the current bugs.

Second: This PR to be able to log the email address associated with a particular message, this PR adds code to query Postgres for their email – we don't need the user email for anything else. This may add unjustified overhead (though it is fairly minimal; we query Postgres only once per connection). If we are looking for performance improvements in the future, we can remove this logging and switch to logging only the less-descriptive numerical user id.