CLC-3420: Spinner is intoxicated on Firefox
https://jira.ets.berkeley.edu/jira/browse/CLC-3420

It looks like the spinner had a couple of :beers: at the Firefox headquarters. This PR should make him sober again.
Merge pull request #2221 from christianv/CLC-3420

CLC-3420: Spinner is intoxicated on Firefox
CLC-3248-backend-for-user-alerts - Revision 1

Changes made to the AppAlertsProxy

https://jira.ets.berkeley.edu/jira/browse/CLC-3248

Summary:

Tried cleaning up the specs in general and stop expecting logger error calls that are handled by Cacheable anyway.

- removed all begin and rescue structs from all methods because the only public method is get_latest, which wraps its response eith smart_fetch_from_cache where the error returned (or not) to the user is handled at a higher level.
- I chose to use smart_fetch_from_cache's return_nil_on_generic_error option because at the moment it's either there or it's not, and I have no current need to form my own reponse messages as done in the financial proxy, which does expect different errors and sends a message and ann http status code.

  {
    body: "some kind of message",
    status_code: 400
  }

- I'm not sure how standard are responses are, but maybe this reponse could be encapsulated in a homegrown class unless an existing one exists and serves better.
- I renamed some of the private methods.
- I wrote a validator that checks that the expected entry fields exist with values and logs an error if they are unexpected. This part could be written as a part of a model, but there is no real model here, and no ActiveRecord. It's just a proxy, so that's why I validated here.  Is there a better place to put validation in this case?  It's good to check the responses, right? I'm just not sure if this this the best place or least expensive way.

- I removed the begin-rescue from get_alerts,
  I can reproduce a Nokogiri::XML:SyntaxError in get_alerts if it was ever called directly,which it shouldn't be, because it's private, at least for now.
  Anyway, I made a spec to demonstrate that this error couuld happen if get_alerts was ever called directly without being passed through smart_fetch_from_cache.

with the get_raw_xml method, I haven't seen it trip on any of the finding of xml docuents on disk or json responses returned by http.
- use let instead of before blocks

Also added alert to unlogged dumy status feed