Fix performance problems

[jechols]

If we're going to keep maintaining this plugin, there are some fixes we desperately need. UO has chosen to go with an in-theme version of this plugin, and we found a way to dramatically improve performance. (see https://github.com/uoregon-libraries/oregon-oni/blob/master/views.py#L47-L76)

For "this day" functionality, we construct a full date in code instead of using django magic to select by month and day. This is a significant performance boost since it queries on an indexed field. But it can also lead to a lot of misses since some years have very few issues. We built in logic to make up to ten attempts before giving up and falling back to the random "featured page" approach. In UO's case that will probably work most of the time because we have so much content, but we'll have to monitor it closely. But it's possible to make this work more generally, we'd need to allow dozens of tries, at which point there is no savings over the previous search which was slow but never did more than one query.

For the random page functionality, we rely on an SQL query to sort randomly instead of pulling random indices from the full list of issues.

UO hasn't bothered (yet), but caching the chosen page really should happen. That way even if things are slow sometimes, it's a performance hit only once for the day, not every hit to the homepage.

[jduss4]

I like the idea of caching the pages of the day, definitely. Not sure I would be comfortable putting the "attempts" style you describe above into this plugin.
I'm suddenly curious what the LoC did in their original chronam stuff, because I'm fairly certain they had an "on this day" carousel...

[jduss4]

Well. They picked a very different solution to the problem: https://github.com/LibraryOfCongress/chronam/blob/master/loc/templates/home.html#L21

They used "100 years ago today" + ajax