Goals

Simplify error reporting, especially for users who file bugs (no more telling them to enable logging, manually uploading the file, etc.)
Get statistics on error frequency (to help with prioritization)
Detect the "long tail" of problems that are never filed

Proposal 1: a dedicated service

If it encounters a non-trivial error, Sync uploads the log to the service via HTTPS POST.
Lines with TRACE are automatically removed as they often contain sensitive information (need to audit Sync's logging for this!)

Same as Proposal 1, but instead of uploading to a dedicated server, Sync would uploaded the logs to a special collection on the user's Sync node.

Pro: No new server infrastructure required, scales as the Sync backend is scaled. (The client is pretty much oblivious to *where* the data is uploaded.)
Con: If the user's Sync node is experiencing problems, the error report may not be uploaded. So a failure in the Sync db would also inhibit the client from uploading the logs about it.
Con: We won't get any data from people with custom servers.
Con: Logging data normally contains data that's less confidential than the Sync data itself, but when it does it won't be encrypted. Thus it would make sense to have a separate service that has separate infrasec requirements.
Con: The URL to identify an error will point to the user's node and will thus require the user's credentials to access: impractical

Should this be
- always on and not configurable, or
- ask after every error (with the option to remember the user's choice for future incidents),
- off by default and opt in, or
- on by default and opt out?
Will this service require ToS changes?