Code review comment for ~bryce/ubuntu/+source/fetchmail:fix-2035-hirsute

'set -x' implies 'allow-stderr' will be needed. Duh. Yeah why was I overthinking this.

However, I would prefer not to set allow-stderr, because actually it's been quite useful in development to be strict about stderr messages, and I took efforts to deal with all "regular" stderr messages, so if more pop up I'd like to treat them as actual problems. I am guessing the same problem will exist with adding "exec 2>&1", although that does seem like a clever approach I'll try to remember for other situations.

However, I think it may be okay to just go with option #1. In the mock server, I sprinkled dbg() commands at keep points to assist in spotting where errors might occur. Most of the problems I ran into during development were in either serve() or process(), which is why they have 10 dbg()'s between the two of them.

So, to sum up, I'd like to stay strict with treating stderr content as erroneous, and just rely on being verbose with debug messages for tracing program flow.