Event comparison correction, etc.

Corrections in the comparison logic of the EVENT/TYPED_EVENT hierarchy: The
postcondition of is_equal (in ATOMIC_MARKET_EVENT and TYPED_EVENT) sometimes
failed - i.e., the implementation was wrong. Fixed by removing the
redefinitions and using the ancestor version.

eiffel_library:

NON_PERSISTENT_CONNECTION_INTERFACE (in eiffel_library): In
'process_request', number.to_integer was being called several times.
For efficiency, assign the value, in one place, to a variable.

SETTABLE_HTTP_URL: Corrected postcondition of http_make - e.g.:
host_set: host /= Void and host = h
  ->
host_set: host /= Void and host.is_equal(h)

Etc.
First commit for socket-enhancement: keep socket open

In preparation for keeping socket connections open after responding to a
client request, began implementing logic for flexibility in the
client/server communication protocol such that the server can be configured
to either close the socket connection after each response it sends (and,
via 'listen/accept', open a new connection when the client sends its next
request) or keep the socket open (until, according to the current plan, a
cache of connections grows beyond a limit).  Implementation of the latter
functionality is still in progress, but the former (which basically
implements the original behavior) is working, with some aspects duct-taped -
i.e., needs to be properly designed/refactored; working means it passes the
suite of tests in my (new) ruby-based client.  This new
design/implementation includes a new attribute, close_after_each_response,
in MAS_SOCKET_ACCEPTOR, which, when true, will cause the original behavior
(close after each send, re-open for new request, ...), as well as a new
class (in the eiffel_library), CONNECTED_SOCKET_POLL_COMMAND.  More
infrastructure needs to be put in place to support the new (keep connection
open) behavior.

Another added detail is an extension to the client/server protocol:
When the server will be closing the connection after sending a response, it
will send a different "OK" code compared to when it will not close the
connection - with a new constant named ok_will_close, so the client needs
to check for either the ok or the ok_will_close status and, if the status
is ok_will_close, get ready to open a new socket for its next request.
(This will, of course, be incompatible with old clients, such as the java
client - MA_Client.)  To complete this extension, alternate codes also need
to be implemented for the different error statuses - e.g.,
invalid_symbol/invalid_symbol_will_close, ...

Among other changes, the new implementation includes a redefinition of
'post_process', in MAS_SOCKET_ACCEPTOR, where (if close_after_each_response
is false) it creates a CONNECTED_SOCKET_POLL_COMMAND that holds the new
socket obtained via the 'accept' call.  This will be the socket that stays
open as long as the client is still around and as long as the (to-be-
implemented) cache has not filled.
Redesign/refactoring for socket-enhancement

The major work of redesigning to allow sockets that stay open between
request/response transactions while allowing the option of keeping the
existing behavior (close after each transaction) is complete.  Note that
the original behavior (close socket after each response) is the default.
Highlights (eiffel_library):

  - name change: SOCKET_ACCEPTOR -> SOCKET_PROCESSOR
  - Moved code from SOCKET_PROCESSOR that manages the server-socket
    functionality (i.e., bind, listen, accept) into a new class,
    SERVER_SOCKET_PROCESSOR.

Highlights of MAS-specific changes:

  - Added logic for the alternate, keep-socket-open behavior, including a
    new environment variable (MAS_NO_CLOSE) for configuring this behavior,
    and a couple features/attributes at appropriate places (such as
    no_close_after_each_send) to indicate this behavior has been requested.
  - New constant values (201 - 205) with appropriate names, mirroring the
    status for the request in the response to the client (error, ok,
    invalid*, ...) while at the same time indicating to the client that the
    "will-not-close-socket-after-sending" behavior is in effect.

Also, changed some inheritance specs (by adding the {NONE} tag) to indicate
non-conforming inheritance.
Further implementation of socket-enhancements

EIFFEL_LIBRARY:

CONNECTED_SOCKET_POLL_COMMAND:  It now depends on CONNECTED_SOCKET_PROCESSOR,
which means it needs to be moved to where CONNECTED_SOCKET_PROCESSOR
resides - the mas/finance repository.  (This could probably be fixed via
some refactoring and a new class, but there may not be time for that.)
Added some 'cleanup' logic (remove_read_command, close socket) via new
feature, final_cleanup.

general: Added some error-handling/reporting logic.

MAS/FINANCE:

general:

set CONNECTION_CACHE size to 1 to allow testing of the
remove-the-oldest-poll-command behavior (and resulting cleanup) with only 2
clients running at the same time.

Some changes to return the server-will-not-close (after responding)
response codes for error conditions to let the client know that (as with a
normal/ok response) it should not close its connection - i.e., it should
use the same socket connection for the next request rather than creating a
new one.

Added some logic to ensure that when a CONNECTED_SOCKET_POLL_COMMAND is
removed from the CONNECTION_CACHE the following behavior occurs:

  - The poll command and its associated socket are available for one more
    request/response to the associated client.
  - When the response is sent, the connection-will-be-closed response code
    is sent (rather than the usual ...will-remain-open code) to reflect the
    fact that the associated socket has been kicked out of the cache.
  - After the response is sent, the associated socket is closed.

This design - of allowing one more request/response communication with the
client to occur after removal from the cache - appears to be the most
straightforward way to ensure that the client is notified that the socket
will be closed after the last response from the doomed socket.

CONNECTED_SOCKET_PROCESSOR: New (SOCKET_PROCESSOR) class for handling open
TCP socket objects (as opposed to server sockets, which listen/accept/...).
Moved mas/finance-dependent file from eiffel_library to here.

Moved connected_socket_poll_command.e from the eiffel_library repository to
this one (by creating it as a new file here), since it depends on
CONNECTED_SOCKET_PROCESSOR in this repo. For the (short) history of the file
in eiffel_library, the former location (in eiffel_library) is
networking/connected_socket_poll_command.e.
Completion of socket-enhancement feature

Completed implementation of keep-socket-open behavior.  Completed logout
functionality when MAS_NO_CLOSE is in effect, with respect to the session
being logged out:

  - Close the associated socket.
  - Remove the associated CONNECTED_SOCKET_POLL_COMMAND from
    MEDIUM_POLLER's read list.
  - Mark the CONNECTED_SOCKET_POLL_COMMAND as expired so that it will be
    removed from the CONNECTION_CACHE the next time a new
    CONNECTED_SOCKET_POLL_COMMAND is added to the cache.

miscellaneous:

  - Made the CONNECTION_CACHE size configurable via environment variable
    MAS_CONN_CACHE_SIZE.
  - Got rid of the 'register_for_termination' call during initialization of
    the SOCKET_PROCESSOR objects (unless the new query
    'termination_required' is true).  This should allow the cached
    CONNECTED_SOCKET_POLL_COMMANDs to be garbage-collected when they are
    removed from the cache instead of waiting around to be "terminated".
  - 'post_process' in MAS_SOCKET_PROCESSOR only creates a
    CONNECTED_SOCKET_POLL_COMMAND and CONNECTED_SOCKET_PROCESSOR when
    is_non_persistent_connection is true, so command-line client
    connections will never use the CONNECTED_* objects.
  - CONNECTION_CACHE: 'add' now removes all items that have 'expired'
    (which state is set by the "logout" process) so that all
    unused/discarded CONNECTED_SOCKET_POLL_COMMANDs/SOCKETs are removed
    from the queue/cache before the new item is added.

Note: A bug appears to have been introduced (or it was already there from
previous work) in the implementation of communicating with the command-line
client: Sometimes the same command (issued from the client) needs to be
entered twice before the server executes it (where the first command is
responded to with an error message).  This does not happen all the time.  I
noticed it when I was running the java GUI client at the same time as macl
(MA_Client.class) for a test, so the bug might be triggered (possibly among
other scenarios) by running MA_Client and then macl.

eiffel_library:

Some small changes to support the mas/finance changes described above.
socket-enhancement work finished, cleanup was needed.

Cleanup after socket-enhancement work: Removed temporary comments,
commented-out (discarded) code, and debug/print statements.

APP_ENVIRONMENT: bug fix: 'connection_cache_size':
After the line:
sz := get (Env_names.connection_cache_size_name)
a guard is needed in case sz is Void after this call, which causes problems
2 lines down (Result := sz.to_integer).  With the bug fix, if sz is Void
Result is 0, an invalid cache size - which causes the code setting the size
of the actual cache to use the default value (currently 20).

MAS_SETTINGS: In miscellaneous_report, added report of the connection cache
size.