Sidekiq configuration.
Stub out job queuing for EventSearch objects.

Scheme: one job = one search.  Individual searches will most likely run
HTTP requests in paralle from there.
Cases mock: error out on no-param and no-client-ID cases.
Simulate Ops authentication requirement.

Also make Pancakes satisfy that requirement.
Require CAS authentication for the Cases mock.
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.
Patch over an overly-broad security fix in Rails.

See monkeypatch comments for more information.
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.
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.
Queued jobs need to capture the user's PGT.

Yes, I know it's possible for the PGT to expire between this and job
execution.  Nothing that can be done about that, though.
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.
Remove stray queue call.
Add rb-readline for some Ruby environments.

Specifically, Rubinius 2.0.0 seems to need this to launch the Rails
console.
Group Redis configuration in its own key.
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.