XIP: add functionality for maintaining neighbor status

struct hrdw_addr needs fields describing the local clock and remote
status (failure status and clock time) of a neighbor. The first 31
bits of remote_sc are the remote node's clock, and the 32nd bit of
remote_rc is the failure status (0 for failed, 1 for active).
local_c is 32 bits of the local clock.

All clock times are taken from the lower 32 bits of the wall time,
measured in seconds. When two remote clock values need to be
directly compared (only the lower 31 bits represent the clock), the
function clockcmp31() should be used, which is a wrapper for
clockcmp32(). When two local clocks need to be compared (where all
32 bits represent the clock), clockcmp32() can be directly called.
These functions correctly handle overflow of clock values.

Because neighbors now have a status associated with them, NWP
needs methods of disseminating that information. To do this,
the routines for announcing and sending neighbor lists must
be amended to include status information, and the packet definitions
for announcements and neighbor lists must be amended. A node will
only send information about a failed neighbor if it is within a
time bound defined by NWP_LIST_TIME_MAX so that failed neighbors
are not cyclically added and deleted from neighbor lists in the LAN.

Status information can be taken from announcement and neighbor list
packets in read_announcement() and process_neigh_list(), and can be
passed to functions that create and insert neighbors, such as
new_ha(), add_ha(), and insert_neigh().

The code outside of net/xia/ppal_hid/nwp.c should know as little as
possible about neighbor status. The global insert_neigh() is
therefore converted into a wrapper function for the static
insert_neigh_status() inside the NWP code. Therefore, code in
include/net/xia_hid.h and net/xia/ppal_hid/main.c is agnostic of
the NWP monitoring algorithm so neighbors can be manually added.
XIP: move error checks for packet dropping

struct general_hdr is not general enough for all types of NWP
packets; only the first two fields are necessary. Therefore, the
error-checking code for the number of HIDs and the hardware
address length should be moved to more local code for
announcements and neighbor lists.
XIP: implement efficient monitoring algorithm

Every struct hid_dev now has a timer to periodically begin a
monitoring interval. It is also necessary to allocate memory
for the hardware address of a temporary target for each
monitoring interval. This hardware address is under a lock
only when it is written-to by the single monitoring thread
and read by the potentially-numerous packet-handling threads.
Reads of this target hardware address in the monitoring
thread do not need to be locked.

There are also flags for whether monitoring is currently
occuring, for determining whether contact has been made with
any neighbor during the current monitoring interval (to
diagnose network partitions), for whether the neighbor has
yet been remonitored if failure is suspected, and for whether
the algorithm is currently in the investigative phase. These
flags are defined in net/xia/ppal_hid/nwp.c.

Upon arrival of a neighbor list, the monitoring algorithm may
begin in process_neigh_list(). monitor() initiates a monitoring
interval, using pick_random_neigh() to select a random target
to monitor.

To accomplish this, the monitoring algorithm first pings the
selected target, which may result in a timer expiration and
callback of end_ping_failure(). In that case, investigative
neighbors may be used to verify that the given target has
failed. If, at the end of the investigative time period, no
response from the target has been received, a timer expiry
callbacks into end_interval_failure(), which may declare a
node as failed.

A function find_update_neigh_sc() is added to update the status
of a hardware address for which we don't have a struct
hrdw_addr reference. If we're updating a node that has failed,
we need to estimate the remote clock time using the difference
between the old clock time and the new clock time. The list
replacement operation is made faster here by the RCU facility.

The forward declaration of end_interval_failure() is necessary
because of the cyclical nature between calls to monitor(),
end_ping_failure(), and end_interval_failure().

In order to send monitoring packets, send_monitoring() is
implemented. Note that const u8 *inv should not be used
for Ping and Ack packets, and in those cases should be set to
NULL.

nwp_rcv() may now accept monitoring packets and distribute
them to process_monitoring(), which updates clocks, changes
timers, and dispatches packets as necessary depending on the
type of packet that has been received. When a monitoring
iteration is successful (an Ack is received), the monitoring
interval will end in end_interval_success().
XIP: clean neighbor list by removing failed nodes

Periodically, the neighbor list should be cleaned of any failed
nodes that have been declared dead for NWP_FAILED_TTL. The function
clean_neigh_list() is therefore added, which is periodically
called upon timer expiration to find such expired nodes and remove
them from the neighbor list.
XIP: fix spelling of announcement

Fix the spelling of "announcement" in a couple of places in the
code.
XIP: disable deletion of manually-entered neighbors

iWhen a neighbor is manually added to the neighbor list via the xip
utility, that neighbor should not participate in NWP and should not
be removed from the neighbor list. These nodes are kept in the
neighbor list to keep routing compatible in other XIA implementations,
but they should not be sent in neighbor lists or monitored.

To do this, insert_neigh() and new_ha() are given an additional
parameter, manual. If this parameter is true, then the node has been
manually inserted. Every struct hrdw_addr now has a u8 manual to
reflect this as well.

clean_neigh_list() also should therefore not discard any neighbor who
is considered manually-entered.