This is some initial development to support SHA2 (SHA256) data-object
hashs ('checksums').  This is incomplete and should not be enabled
except for further testing and development.  I'm committing it so that
Hao and/or I can work on the next steps, coordinating with Mike C.

We have source code for MD5 (authentication and data-object hashes)
and for SHA-1 (authentication), but for SHA-256 I decided to use the
OpenSSL implementation, at least for now.  It may be possible to find
a reliable open-source version of SHA-256 we could include as source,
but the OpenSSL one is very good and easily installed.  On Ubuntu, for
example, this is: sudo apt-get install libssl-dev

To enable SHA-256, update config.mk (using config.mk.template) to
uncomment:
# SHA256_FILE_HASH = 1

That will, among other things, set SHA256_INC=/usr/include/openssl
which is correct on Ubuntu but may be different on other systems.

It should build OK and with that iput -K and iget -K and ils
-L using SHA-256 checksums should work.

But we need to add code to handle both MD5 and SHA-256 in the same
system.  We might add a rule to decide if we should use SHA-256 for
new data-objects but we might need something on the client side too.
For this test version, I just hard-coded a flag to have it always use
sha256.  We might add a string like 'sha256:' at the front of the hash
so we can can have others in the future (and assume MD5 if there's no
prefix) and can give meaningful error messages, but that's only part
of the problem.  There's plenty of space in the ICAT table for the
hash.

This required a few changes in some defines and some of the protocol
defines (not the actual protocol tho).  Mike Wan was using NAME_LEN
for the size of the chksum field, and that's 64.  But the SHA256 hash
(even without a prefix) is 64 bytes itself (MD5 is 32), so it's one
byte too small (to include the trailing null).  So I added a
CHKSUM_LEN and changed the code in a few places to use it.  It was a
little tedious to find, but I got many of them, altho there are likely
others.  NAME_LEN was a shortcut he used (I did similar in many
cases), but it's cleaner to have the separate CHKSUM_LEN defined;
certainly makes it easier to find.

For the core system tho, this means that when sites start using SHA256
file hashes, the older versions of the i-commands might fail on those
data-objects.  So we need to check into this more and decide if we
need to make separate protocol messages for the new checksum size (if
it's worth the trouble and complications).  But if we don't, when
zones federate, users will get errors if their version doesn't support
it.  Even the object-stat call will fail, it seems, so we'll probably
need a new one for that. But the code is using rstrcpy and so will
avoid an overflow and give a reasonable error.  Maybe all versions of
3.3.1 will have the larger chksum size in place, so even if they don't
use SHA256, it will work well (we'll want to have a specific error for
sha256 found but not supported in the local code).  It's likely that
if we do that, and have a new Sha2 object-stat, 3.3.1 would be
backward compatible OK with 3.3 and earlier, as long as MD5 checksums
are being used.

If you grep for chksum and NAME_LEN you'll see other cases where we
might need to change NAME_LEN TO CHKSUM_LEN.  lib/core/src/rcMisc.c
has some, however it's looks like it might be assuming all the various
fields are at most NAME_LEN characters long, so we'll need to check
into that more.



git-svn-id: svn://irodssvn.ucsd.edu/trunk@5612 ea137bd6-aa86-47b6-b90d-b101d9f19a90