Merge pull request #2213 from chikoon/CLC-3248-backend-for-user-alerts

CLC-3248-backend-for-user-alerts
CLC-2548 Update grossly out of date my/status JSON contracts before any refactoring
On branch NO-JIRA-acitivities-scss-cleanup

Removed references to the undefined css class "cc-widget-tasks-activities-more"
Merge pull request #2216 from chikoon/NO-JIRA-acitivities-scss-cleanup

On branch NO-JIRA-acitivities-scss-cleanup
CLC-2548 Remove another unneeded dummy JSON; fill in a few more items
Merge pull request #2215 from raydavis/raywip

CLC-2548 Update grossly out of date my/status JSON contracts
This is a good start on refactoring the dummy feeds to be used for testing.  I am still concerned about minifying to maximumly the amount of dummy files and the differences in information they may contain.
CLC-3247: Implement: User Alert message in front-end
https://jira.ets.berkeley.edu/jira/browse/CLC-3247
Merge pull request #2217 from christianv/CLC-3247

CLC-3247: Implement: User Alert message in front-end
CLC-3409: Implement Splash page text changes in CLC-3348
https://jira.ets.berkeley.edu/jira/browse/CLC-3409
Merge pull request #2218 from christianv/CLC-3409

CLC-3409: Implement Splash page text changes in CLC-3348
Basic text message changes to the splash page. Looks good to me!
CLC-3292 - Add People: Change target of help links
Merge pull request #2219 from redconfetti/CLC-3292-change-target-help-links

CLC-3292 - Add People: Change target of help links
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