Bug 11112: Koha::Calendar needs some caching

Bug 11112: Koha::Calendar needs some caching

Each time a Koha::Calendar object is created, its constructor retrieves
all holidays from the database and create a DateTime::Set object with
all holidays.

[RM note: I've observed that the time it takes DateTime::Set to be
 initialized with a set of dates increases faster than linearly with
 the number of dates.  I think this, more than just retrieving a bunch
 of holidays from the database, is what is most expensive.]

In one of our customer's DB, there are 11085 special_holidays and 598
repeatable_holidays. When a loan is returned, there are 3 calls to
Koha::Calendar->new.

This patch adds caching of the holiday list via package-level variables
as well as lazy fetching of the holidays. (RM note: this means that if
a persistance engine is in use, updates to the holiday list will not
be reflected during checkout.  I'm allowing this breakage for now on
the plan that bug 8089 will be fixed soon and we can switch to using
Koha::Cache).

Nytprof benchmarks (on a 3.8.x branch):
In DateTime::Set->from_datetimes:
3 times (5.49ms+4.90s) by Koha::Calendar::_init at line 80 of Koha/Calendar.pm, avg 1.63s/call
on a total of 7.67s (of 10.2s), executing 6353333 statements and 3031273 subroutine calls in 147 source files and 36 string evals.
for the circulation/return.pl page.

Comparing the access_log:

Without the patch:
checkout: time=2759838
checkin: time=1832751

Without the patch and with overdues:
checkout: time=1086727 + time=1144706
checkin: time=3928854 (x2)

With the patch and overdues:
checkout: time=1077839 + time=1060886
checkin: time=2420898

Test plan:
- checkout an item with a return date < today
- checkin the item and verify the suspension period is well calculated
  (depending on the holidays).
- prove t/db_dependent/Holidays.t
- t/Calendar.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>