Add better login failure messages.

[Philip Burns]

A login failure doesn't generate a descriptive error mesage. We should add one.

[Craig Berry]

Resolved by:

commit dbcd636bb816dc7931d84c82bd37bf0f4e670972 (HEAD -> master, origin/master, origin/HEAD)
Author: Craig A. Berry <[e-mail]>
Date:   Sat Aug 4 15:27:28 2018 -0500

    Make logging in more robust and informative.

    As was the login form just tossed credentials over the wall and
    hoped for the best.  There already was a "login" resource in the
    controller that sent a JSON response, but the login form wasn't
    using it or attempting to process a response, and the response
    had a validity error in the JSON it was sending.

    So rewrite the login form as a proper AJAX request that gets
    routed to the login processing on the server side and then handle
    the response.  While we could in principle send a 401 response
    for failed authentications, that then requires a WWW-Authenticate
    header, and we don't have an appropriate one for which our login
    form can respond to the challenge.  So make authentication failure
    a 200 response with a failure message that we can parse and pass
    on to the user, adding a new div on the form to display that
    message.

    Also replace some deprecated functions in the controller login
    handling (xmldb namespace) with the currently-supported versions
    (sm namespace).

    Unfortunately eXist provides no method from XQuery to trap the
    reason for an authentication failure, i.e., whether the user does
    not exist, the password is incorrect, or the session has timed
    out.  So we're stuck with a pretty generic error message, but at
    least now there is some feedback about whether a login attempt
    was successful.

    N.B.  While the absence of feedback added to the annoyance factor,
    the root of our login problems appears to stem from a disagreement
    between Apache proxying and Jetty.  Jetty kept downgrading the
    AJAX request from https to http, causing the browser to detect
    mixed content and reject it.  The solution to this turned out to
    be adding this to the Apache settings in 000-default-le-ssl.conf:

       RequestHeader set X-Forwarded-Proto "https"

    and this to the Jetty settings in jetty.xml:

         <Call name="addCustomizer">
           <Arg><New class="org.eclipse.jetty.server.ForwardedRequestCustomizer"/></Arg>
         </Call>