Enhanced Billing Timestamp Support

[Dan Wells]

As discussed at Hack-a-way 2016, rather than continue to try to cram multiple meanings into one timestamp, let's create a complete set of all the useful timestamps for a typical billing.

In this new config, every billing will have a 'create_date', then most (overdues) will also describe when they start and end.

billing_ts is now deprecated, but will continue to exist for backwards compatibility. It will be managed by trigger to approximate its current definition; equal to 'period_end' for overdues, equal to 'create_date' for other billings.

[Dan Wells (dbw2)]

Branch for consideration at:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1748924_redo_billing_timestamps

working/dbwells/lp1748924_redo_billing_timestamps

This is a major rethink of some billing timestamp work done locally a few years back (see LP#1422379), and now that it is done, I think we may still end up reimplementing a COALESCE(period_start, create_date) single value in the long run, but we'll see how that plays out.

This branch attempts to make the minimum changes to allow for this DB enhancement. Should this be accepted, I have several other bug fixes which build on the availability of these new values.

[Dan Wells (dbw2)]

Added pullrequest, but would love more conversation before this goes in. Are we being to conservative in keeping the current meaning of billing_ts, rather than making it a very-close-but-more-intuitive version of itself?

[Dan Wells (dbw2)]

After further reflection, I think this branch is an iterative improvement regardless of what happens in the future, so that discussion can happen post-beta or even post-3.1. After churning for years on bug #1422379, any step forward on this would be very welcome!

[Jeff Godin (jgodin)]

Running the upgrade script on a copy of production data confirms significant benefit from disabling trigger(s).

Pushed to master in the name of baby steps everywhere -- thanks, Dan!