FCPInterface: Begin adapting to fred branch plugin-fcp-rewrite

- Add FIXME of replacing the ClientTrackerDaemon with the public API of
plugin-fcp-rewrite. (It has a backend daemon called
FCPPluginClientTracker which does the same job)
FCPInterface.ClientTrackerDaemon: Add FIXME about handling of
InterruptedException

- Thread.interrupted() is a getter, not a setter. It probably should
have been interrupt(). I didn't read the bugtracker entry though because
the code will be commented out in the following commit anyway.
FCPInterface.ClientTrackerDaemon: Remove garbage collection thread

- The fred code of branch plugin-fcp-rewrite will provide this as an
API, no need to implement it in WOT anymore. (See
class FCPPluginClientTracker there)
- The get() and put() are kept since I'm not sure whether the fred code
will be usable in unit tests yet. So if we change ClientTrackerDaemon to
be an interface to FCPPluginClientTracker, it will be possible to make
it use the HashMaps in unit tests in case the fred code does not work
there.
FCPInterface.ClientTrackerDaemon: Finish basic implementation of using
plugin-fcp-rewrite

- Implement get() to use the new fred API:
* Return FCPPluginClient as thats the new representation of the remote
end instead of PluginReplySender. Use UUID as thats the fred-side
ID-type for FCPPluginClient
* Throw IOException since thats what the fred getter throws. Notice that
IOException is what shall be typically thrown in Java if a network
connection was closed meanwhile, so this is the right thing here.
- Leave put() empty as fred stores FCPPluginClient objects
automatically. But keep it for now since the fred stuff probably won't
work in unit tests yet. Document  the unit test issue with a FIXME.
- Add FIXME for removing the class as it merely is a wrapper around the
fred stuff now. Again, keep it for the unit tests.
- Add FIXME about the obsolete JavaDoc
FCPInterface: Delete class ClientID

- With the branch plugin-fcp-rewrite of fred, this class is not needed
anymore. There, clients are identified by UUID objects.
Indent.
Indent.
WebOfTrust: Use new plugin FCP interface
FredPluginFCPMessageHandler.ServerSideMessageHandler

- Adaption of class FCPInterface will follow
FCPInterface: Begin implementation of new interface
FredPluginFCPMessageHandler.ServerSideFCPMessageHandler

First steps here are to:
- Rename the message handler function
- Make sure it does not process reply messages because those should not
arrive here: WOT only does send messages to the client which shall
receive a reply using *synchronous* sends. Synchronous sends will have
their reply returned to the blocking send function instead of having it
passed to the message handler. Anything else sent by WOT should not
receive a reply. Thus, reply messages should not arrive in the
async message handling function.

The rest of the body of the function will be adapted in the following
commits.
FCPInterface.handlePluginFCPMessage(): Finish adapting to new interface,
fix bogus data sending

- The designated way of sending a reply FCPPluginMessage with the new
API is to return it, not to send it using the FCPPluginClient. So we do
this now.
(- The FCPPluginClient may still be used for out of band messages, i.e.
non-replies, this is why we pass it to the handleSubscribe)
- The new implementation of errorMessageFCP will follow, as well has
handleSubscribe
FCPInterface: Specify deprecation mechanism for fields of the
SimpleFieldSets which WOT sends

- The plugin-fcp-rewrite of fred will have special standardized
errorCode and errorMessage values natively at fred plugin FCP messages.
Thus, the following commits which adapt the
FCPInterface.errorMessageFCP() will have to deprecate the old error code
and message fields which were previously put  into the SimpleFieldSet of
the message in a non-standardized way. So it is a good time to
standardize a deprecation mechanism for SFS entries of WOT.
- I chose to include the deprecated field list in the actual on-network
data to ensure that client authors read them :) Also, it will make it
easier to understand dumps of raw FCP traffic. For example during the
RFC of event-notifications, I had supplied a dump to the mailing list.
But as it contained lot of deprecated fields, people got confused and
had to ask about the duplicate fields and which ones are the right ones
etc.
FCPInterface.errorMessageFCP(): Fix to work with new errorCode /
errorMessage fields of fred branch plugin-fcp-rewrite

- Have two copies of the function:
* One for eating generic, unkown Exceptions. They will be specified as
errorCode = "InternalError" as requested by the plugin-fcp-rewrite API.
* The other for specific, well-known exceptions such as "there is no
Identity with the ID you specified" which can have a proper errorCode
which is parsable by the client.
- Tell the user to prefer the one with the proper error code in the
JavaDoc.
- Also add a FIXME at the function which uses the errorMessageFCP() the
most to specify proper error codes.
- In conclusion, deprecate the "Error" and "Description" custom,
non-standard WOT fields and add a TODO to remove them after some time
- Notice that the value of OriginalMessage is correctly set as it was
previously passed by the caller which was changed to use the new
function signature at c9b524c69128fcc826207d2a67b05f76ecbbac2e: The diff
of that commit shows the value
FCPInterface.errorMessageFCP(): Use new FCPPluginMessage shortcut
constructor

This is available as of fred plugin-fcp-rewrite commit
07d8db6767b21093e3987b6a9d65bda67d3281e4
FCPInterface: Fix initialization of final field with null
FCPInterface.handleSubscribe(): Draft new specification of how
subscribing will work with the new fred plugin-fcp-rewrite

- This is not implemented yet, the implementation will follow. A FIXME
is added to the JavaDoc
- Since plugin-fcp-rewrite uses proper "identifier" values of FCP
messages and thus clearly marks messages as being replies to other
messages, we do not have to describe the process by mentioning
"synchronous" FCP calls anymore :) WOT will probably implement it as a
synchronous call internally, but the only thing which it needs to be
externally visible is the fact that the client has to reply to the
synchronization message specifically.
FCPInterface.handleSubscribe(): Begin to adapt implementation to fred
plugin-fcp-rewrite

- ClientTrackerDaemon.put() is changed to not throw so the code will
work for testing
- The FIXME at the JavaDoc to adapt it is not removed yet since part of
what is specified at the JavaDoc is done by the callees of
handleSubscribe(), which this commit does not change yet.
FCPInterface: Use UUID instead of Strinf for IDs of FCPPluginClient
FCPInterface.handleUnsubscribe(): Remove TODO about cleaning up the
ClientTrackerDaemon

- With fred plugin-fcp-rewrite, the client objects are managed
automatically by fred. The ClientTrackerDaemon only still exists for
unit tests, and they won't need cleanup.
FCPInteface: Rename "fcpID" variables to "clientID"

- Those are all IDs of a FCPPlugin*Client*
FCPInterface.handleUnsubscribe(): Adapt to
plugin-fcp-rewrite

- Return a FCPPluginMessage instead of SFS since
sendUnsubscribedMessage() will want to pass the return value of
handleUnsubscribe() into FCPPluginClient.send()