Request limit SocketTimeout; redundant polling

If the album art request limit is reached (which may occur with some frequency if many users are concurrently polling coverartarchive.org), a fatal SocketTimeoutException may happen. This may apply to other third party APIs as well, but I've only seen this happen with coverartarchive. We'll probably want a safeguard for connection issues.

Additionally, our observers are firing much more often than they should, which is the likely culprit for rate limit excesses. The observers fire on each database field update, and so we're making redundant polls to the APIs. (E.g. the topAdds and topAlbums on Home are being repolled when we update their DB entries with fetched info). This can probably be fixed with boolean guards around our observers that are set to true upon the first non-empty observation.

Stack-trace isn't super informative but the issue seems straightforward enough:

"E/AndroidRuntime: FATAL EXCEPTION: DefaultDispatcher-worker-9
Process: fho.kdvs, PID: 8520
java.net.SocketTimeoutException: failed to connect to ia803006.us.archive.org/207.241.233.26 (port 80) from /192.168.0.208 (port 44910) after 9999ms"

https://wiki.musicbrainz.org/XML_Web_Service/Rate_Limiting