Patch over an overly-broad security fix in Rails.

See monkeypatch comments for more information.
Sidekiq configuration.
Cases mock: error out on no-param and no-client-ID cases.
Simulate authentication requirements for Ops and Cases.

Also make Pancakes satisfy those requirements.
Simulate Cases authorization and internal failures.

The former can happen due to CAS PT processing taking too long; the
latter is just the way life goes.
Stub out job queuing for EventSearch objects.

Scheme: one job = one search.  Individual searches will most likely run
HTTP requests in paralle from there.
Run an EventSearch across all its locations.

Please do note that this commit doesn't actually include retry; it'll
fail as fast as possible.  I'm working on that.
Documentation cleanups on server-side models.
Searches should be mutable.

There's quite a horrible hack embedded in this commit, which has to do
with an odd interaction between associations and transactions in Ember
Data.  I'm writing up a bug report.
A query executor.

Coming up next: translating this into status data.
Use the query executor to retrieve data from Cases instances.

This gives us retry, timeout, and parallel execution.
Add rb-readline for some Ruby environments.

Specifically, Rubinius 2.0.0 seems to need this to launch the Rails
console.
Generate and return a status URL for an EventSearch.

Also stub out the associated GET /api/v1/event_searches/:id/status
endpoint.

Further commits will add functionality to the frontend to periodically
poll this URL for search results.

Just a rationale: This won't be backed by an Ember Data model because
there's no point in doing so.  Event search status *could* be
treated as a resource and subject to all of the machinery that Ember
Data brings to bear, but we really just need that information to update
stuff in the page.
Poll for query status about once a second.
Centralize all event report-related code.

Previously, this was split across EventSearch and StudyLocation, and I
had a hard time figuring out where I should put things like status
updates.  This commit moves all the event report generation code into a
single class, which I think will be easier to deal with.
Send status URL as a Link header.

There's a long story behind this one, so I'm going to just write it out
here.

Ember Data's current support for embedded has-many associations is
really spotty.  It will serialize them just fine, but reading them back
into a just-serialized record just doesn't seem to work at all right
now.  The short version is that associated records do not seem to fully
participate in the same state transitions as their parent, which means
that an associated record will be in state inFlight (or uncommitted) and
suddenly receive a loadedData event when server-supplied data arrives.
That event isn't legal in either of those states, and we get an
exception.

As far as I can tell, that's an Ember Data bug.  But it's something that
I've got to live with.  (Dumping Ember Data is a possibility, but I
think it's too late for that.  Lesson learned for next iteration.)

HOWEVER, if we return *nothing*, then Ember Data's RESTAdapter doesn't
modify the record's contents at all, which sidesteps the symptom.  (Are
the associated records in the wrong state still?  Yeah, probably.  I'll
find out soon enough if that'll screw anything else up.)

Hence this change.  We now return nothing (which is the default behavior
of the ActionController responder on a PUT, anyway) and throw the
associated URLs in a Link header.  This is, to the best of my knowledge,
an acceptable use of that header.

(One other nice side effect: status URLs will no longer go stale if e.g.
the app hostname changes.)

This prevents the state transition errors in Ember Data, but -- as I
said -- likely doesn't fix them.  It does buy me some time to file a
proper bug report and/or figure out how I'm holding it wrong, though.

The next bit of this data-to-header conversion is to extend
Pancakes.Adapter and Pancakes.EventSearch to respectively fetch and
store the status URL.
Replace Ember Data with a custom store.

I'm sure Ember Data will in time become a fantastic library.  However,
presently, I've lost quite a bit of time in making persistence work with
the following (simple) scenario:

   EventSearch - 0..* --- 0..* - DataCollector

Similar multiplicities apply for EventType and StudyLocation.

The frustrating thing is that data _does_ reach the server; I just have
problems with the record lifecycle (see previous commit).  But even with
transaction micromanagement (i.e. adding all dirty records to a
transaction), I keep hitting those lifecycle errors.

Doubly frustrating: I can get this sort of thing to work in a test app,
but not here; the bad interaction is quite elusive.

I therefore have to conclude that Ember Data is indeed not production
ready in the most severe sense.  We'll check in every now and then; see
https://code.bioinformatics.northwestern.edu/issues/issues/show/3993.

---

This commit eliminates Ember Data and replaces it with a very rough but
working replacement.  The server-side behavior is unchanged.  The jQuery
uritemplate and linkheaders plugins are present because they're used for
parsing the Link: header.

All models now use "id" as their primary key; however, no keys were
removed.  This is why the DataCollector model was introduced, and why
EventType has both "id" and "local_code" attributes.
Add Sidekiq to the Procfile.
Merge branch 'no-ember-data'