HTTPServices not threadsafe.

[DennisHeimbigner]

John Caron pointed out that running Tdm with more that a single thread
causes HTTPSession to hang depending on the #threads.

Additionally, UrlAuthenticatorDialog.java was not being invoked after a bad
password was used. This appears to be a misunderstanding on my part about
how apache httpclient is now (4.5+) handling credentials caching.

[DennisHeimbigner]

The primary problem to be addressed was the observation by John Caron
that Tdm was getting hung if ran with more than one thread.

Secondarily, there was a problem with 'UrlAuthenticatorDialog' not being
able to handle bad inputs; it did not ask again when they failed. Note
that this error typically was seen when accessing a password protected
dataset using 'ToolsUI'.

Solution WRT to the threading problem:

First, I created a testcase to show the problem. This is called
'TestThreading'. If run under original version 5.0.0, it hangs when the
thread level is above a certain level.

Second, I centralized all of the connection management code into a new
class called 'HTTPConnections'. I then carefully synchronized it. I
then modified other httpservices module code to utilize this class.

This seems to solve the problem in that TestThreading works with large
(~100) numbers of threads. Unfortunately, I cannot pin-point what
changed that fixed the problem.

Solution WRT to the 'UrlAuthenticatorDialog' problem.

First, I created an alternate and simplified Dialog box for testing
purposes. This is called 'Login'. I then added a test to 'TestAuth'
(now renamed to 'TestTomcatAuth') to utilize this dialog box to show the
problem.

The issue was an interaction with Apache httpclient credentials
caching. I was keeping an internal (to UrlAuthenticationDialog) database
mapping AuthScope->Credentials. My mistake was in storing the results of
the interactive dialog in the internal database rather than letting the
Apache httpclient cache store it. The result, for bad credentials, was
an inconsistency between the internal database and the apache library
cache.

The reason I had put the internal database into 'UrlAuthenticationDialog'
is that, ideally, a CredentialsProvider object should contain all the
credentials required for responding to all authorization requests from
the client to the ultimate server. This is the purpose of the
CredentialsProvider#setCredentials() method. The reason this may be
needed is that as the client wends its way to the server, it may
encounter, for, example, password protected proxies, and/or
redirection-based authentication (e.g. OAUTH2) before it even gets to
the server. The server itself may then require additional authentication
based on spring-security for accessing specific datasets.

In any case, I reverted 'UrlAuthenticatorDialog' to its original form
that has no internal credentials database. I left it in the 'Login'
dialog, however, for testing purposes. The net result is that if
'UrlAuthenticationDialog' is given a bad set of credentials, it
will report this properly.

There is a potential problem down the road, however, in that
'UrlAuthenticationDialog' as it stands is not well suited to handle
calls that require multiple authorizations along the path from client
to server. So, at some point, this will have to fixed.

Other Changes

• The original 'TestAuth' was failing because Caron introduced
  spring-security to control access to datasets in the new class called
  'TomcatAuthorizer'. So, I renamed 'TestAuth' to 'TestTomcatAuth' and
  modified web.xml and catalog.xml so that it tested only using
  container-based authorization and by-passed spring altogether. This
  change also required adding a new root called 'containerauth' to the
  catalog. This caused some unforseen failures in some other tests
  because the number of roots in the catalog changed from 3 to 4. The
  affected tests were 'TestConfigCatalogBuilder' and 'TestDatasetScan'.
• In the process of revamping the Dap4 parsers, I rebuilt
  'Dap4ParserBody' and 'CEParserBody'. Also I removed the
  copies in dap4/grammars from github because they can
  are generated files.
• Removed hold-over reference to thredds-dev in 'TestDir'.
• Misc. changes to the 'HTTPMethod#getURI' to return the URL object
  instead of the .toString() result. this introduced some back
  incompatibilities, although I doubt any external clients are using the
  affected method.
• Certain methods in httpservices are public purely for testing access.
  I modified them to require that HTTPSession.TESTING be set to true
  in order to access those methods.
• Added a new documentation file called 'ssh.adoc' to better
  describe how ssh support in tomcat should be handled.