Zero out MISSEDPK counter in paper_init.sh

Sometimes a few packets are missed during system startup.  This clears
the MISSEDPK counter for instances that are being started.  First all
requested instances are started, then the MISSEDPK counters are zeroed
out.
Validate FID in paper_net_thread

The recevied FID should never be out of range unless an F engine is
misconfigured or there are bit errors in the FID field of the packet.
We have experienced the latter (bit errors in the FID field) and found
that invalid FIDs can lead to calculated pointers that point beyond the
end of the buffer to which they are supposed to point leading to to a
segfault.  Rejecting packets with invalid FIDs will prevent these
crashes, but it does not prevent bit errors that change a valid FID into
a different-but-still-valid FID from going to the wrong place in the
buffer.
Make paper_init.sh output more meaningful

Print the full instance name (e.g. "px1/0") instrad of just the instance
number.  Also print message about resetting MISSEDPK counts.
Change how paper_init.sh backgrounds hashpipe

This makes it more amenable to running paper_init.sh from an ssh command
line (e.g. "ssh px1 paper_init.sh 0 1 2 3").
Validate XID in packet header

Make sure we get a valid XID in the packet header.  If we don't, reject
that packet.  Invalid XIDs can be caused by misconfigured F engines,
incorrect 10 GbE network cabling, or bit errors that affect the XID
field of the header.  In theory, none of those things should ever
happen, but in practice they sometimes do.
Make paper_gpu_thread more robust to mcnt badness

Previously, paper_gpu_thread would only dump to the output buffer if its
input block's mcnt exactly equalled the expected "last_mcount" of the
integration.  There was a check to see whether the input block's was
greater than the epected last mcount, but it would only log such events
and not dump nor would it advance the expected last mcount.  If, for
some reason (such as severe network reliability issues) the expected
last mcount was never seen, then every mcount thereafter will be greater
than the never-to-be-updated-again expected last mcount and so no more
dumps would ever be passed on to the output buffer.  This effectively
stops all data dumps from the X engine instance!

This changes paper_gpu_thread such that it will dump if the input
block's mcnt is greater than or equal to the expected last mcount of the
integration.  It will still log an error message if the input mcnt is
greater than the expected value, but it will "recover" by dumping and
advancing the last mcount value.  This will still lead to two
consecutive corrupted dumps (the current dump that is "missing" the last
mcount but containing one block after it and the next dump that will be
missing at least the one block that got put into the current dump), but
subsequent dumps should be OK (assuming the cause of the missed mcount
does not persist).  If things are so bad that we miss the last mcount of
an integration, then the data are most likely already corrputed anyway
so this is not likely to make things significantly worse.
Make paper_net_thread start in a "hold off" state

When paper_net_thread starts running, it sets the status buffer key
"NETHOLD" to 1.  It then checks the value of this status buffer key once
every second until it has a value of 0.  Once it reads a value of 0 for
NETHOLD, it deletes the NETHOLD key and then proceeds to open the socket
and run normally.  This prevents the net thread of one instance from
trying to read network data while other instances are being started on
the same host.  Starting multiple instances has been shown to cause
dropped packets in started hashpipe processes while the other hashpipe
processes are still starting up.  Using the NETHOLD flag allows the
Linux processes to be started without causing dropped packets (because
no packets are being received) and the confusion (i.e. deadlocks) that
can occur when packets are received too far out of order.

The network thread has a lack of robustness to "missing" packets.  This
lack of robustness is really a bug that should be fixed, but this commit
provides a quick fix that alleviates the primary manifestation of that
bug.
Make paper_net_thread tolerate 8 byte CRC trailer

paper_net_thread now accepts the expected packet size (8+8192 === 8192
bytes) or the expected packet size plus an 8 byte CRC trailer (8+8192+8
== 8208 bytes).  Unfortunately, Zlib's crc32 function is too slow to
validate the CRC values in the packets in realtime.
Add paper_crc_thread and paper_crc_init.sh

paper_crc_thread is a net thread that simply reads the packets from the
network and verifies the CRC at the end of the packet.  Status buffer
keys beginning with "CRC" are created to display the statistics.
Specifically, the CRCPKOK and CRCPKERR fields show the number of packets
received without CRC errors (CRCPKOK) and the number of packets received
with CRC errors (CRCPKERR).

Because Zlib's crc32 function is not fast enough to keep up with the
PAPER dataflow, some packets are dropped.