Bug 7143: Updating history with new developers

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11846: Correct database update for restrictions with date 9999-12-31

The borrowers with indefinite restrictions have borrowers.debarred with '9999-12-31'.

Database update for this bug contained :
  INSERT INTO borrower_debarments ( borrowernumber, expiration, comment )
  SELECT borrowernumber, debarred, debarredcomment FROM borrowers WHERE debarred IS NOT NULL

For borrowers where borrowers.debarred is '9999-12-31', this value
is copied into borrower_debarments.expiration.

This is not correct because borrower_debarments.expiration must be
NULL for indefinite restrictions.

This patch corrects update 3.13.00.035 and also adds an update for
databases already updated.

Test plan :
- Use a database with version 3.13.00.000
- Set a borrower as restricted for ever (leave until empty)
- Use sources to master + patch
- Perform updatedatabase
- Look at borrower details, tab "Restrictions"
=> Without patch, you see Expiration 31/12/9999
=> With patch, you see Expiration Infinite

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

I tested both DB revisions by resetting Version of my database (and
adding a SetVersion after the revised older dbrev). This was possible
since the debarred field still exists in borrowers. (I have my doubts
about that, but that goes outside the scope of this report.)

Also note that routine _UpdateBorrowerDebarmentFlags puts back 9999-12-31
into borrowers for indefinite restrictions (which looks not very consistent).

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11846: DBrev 3.15.00.029

Signed-off-by: Galen Charlton <gmc@esilibrary.com>