Give up on ListenBrainz requests that never answer

[sav]

Submitting happens inside the polling loop, and the HTTP client had no timeout. A request left hanging by a dropped network stopped the whole loop: MPD was not polled, connect() never ran, and the connection never recovered — for as long as the socket stayed open.

Seen in the wild after a night of radio: the process went 1h42 without a single log line, with -v on, while the machine stayed awake the whole time.

gap 101.8 min
   before  07:37:27  reconnected to MPD: localhost:6600
   after   09:19:14  MPD is not playing (state: pause), holding 24.569s

Restarting MPD changed nothing, because mpd-brainz was not looking at MPD — it was stuck in a POST to api.listenbrainz.org.

The fix

One shared http.Client with a 10s timeout, instead of a fresh &http.Client{} per submission.

Testing

A server that accepts the connection and never answers, with MPD restarted mid-request:

master:        current song: "..."  -> then silence for 65s
               loop never reconnected to MPD

this branch:   loop recovered MPD after 6s, ListenBrainz still hanging

Submit itself now returns in 10s (Client.Timeout exceeded while awaiting headers) instead of never. The rest of the suite still passes.

Worth knowing

With ListenBrainz down, one tick can spend two timeouts — the announcement and the listen — so 20s. At the default 30s interval that keeps cycles under MPD's 60s connection_timeout, but not by much, and it is what produces the repeated lost connection: EOF lines in the log above. Not reinsisting on playing_now every tick after it fails would halve it.