rx: Honor RXS_PreparePacket errors

rxi_PrepareSendPacket calls RXS_PreparePacket to allow the security
class to modify the given packet appropriately (to be undone by
CheckPacket on the other endpoint). However, currently
rxi_PrepareSendPacket ignores all errors generated by
RXS_PreparePacket, and processing continues as if there was no error.

For rxkad, an error often results in the given packet being untouched.
This means that the security checksum is not calculated, and thus not
populated in the packet, and for encrypted connections means that the
packet contents are not encrypted.

This occurs for any error generated by the security class
PreparePacket routine. For rxkad, the most common error is probably
RXKADEXPIRED, though some other internal errors are possible as well.

This behavior has a few effects for rxkad:

 1. When any error is generated by PreparePacket, the other endpoint
 generally bails out with the error RXKADSEALEDINCON, since the
 security checksum of the packet is 0, which does not match what the
 checksum should be. This results in error messages like 'rxk: sealed
 data inconsistent'. This can be very confusing if the actual error
 is, say, just that the given credentials have expired.

 2. For connections requiring encryption (rxkad_crypt), an error from
 PreparePacket means that the packet payload is sent in the clear.
 This can happen for about a window size's worth of packets.

 3. If a client ignores errors/inconsistencies with the checksum and
 encryption, etc, they can keep reading data for the call forever,
 even after their credentials have expired.

To fix this, make an error from RXS_PreparePacket cause a connection
error for the given connection, and immediately send a connection
abort. No further error checking should be necessary for the callers
of rxi_PrepareSendPacket, since they already check for call/conn
errors before sending any actual packets.

Reviewed-on: http://gerrit.openafs.org/8909
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Simon Wilkinson <simonxwilkinson@gmail.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
(cherry picked from commit 03d3dacae16847352af754ac13c854ca0df0c08c)

Change-Id: I3c00011d00bda5708a9b91addb5d218eff8439e0
Reviewed-on: http://gerrit.openafs.org/9213
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Windows: AFSWriteCommon collapse redundant condition

We never get non cached and yet paging IO.  Even if we did it would
be inappropriate to call CcCanIWrite.  Therefore, collapse two if
statements into one.

Reviewed-on: http://gerrit.openafs.org/9125
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 6c1d28958db1c0ec50b41274dffa9c58e448a9db)

Change-Id: I61c7dd3375109e4800ed9968fdbfc1bf8072f1df
Reviewed-on: http://gerrit.openafs.org/9214
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>