sane h5df file type check for weights

[BlGene]

If we save a model using hdf5 and load it using caffe.Net it produces the wrong results silently
I would prefer to have caffe.Net check if the filetype is a hdf5 or a protobuff file to avoid confusion.

import caffe
from caffe import layers as L

def conv(bottom, ks_h, ks_w, nout, stride, pad_h, pad_w,
         param_name=''):
  return L.Convolution(bottom, kernel_h=ks_h, kernel_w=ks_w,
                      stride=stride, num_output=nout,
                      pad_h=pad_h, pad_w=pad_w)

def DQN_net():
  n = caffe.NetSpec()
  n.data = L.Input(shape=[dict(dim=[1, 4, 84, 84])])
  n.conv1 = conv(n.data, 8, 8, 16, 4, 0, 0, 'conv1')
  return n.to_proto()

if __name__ == "__main__":
    caffe.set_mode_cpu()
    net_str = DQN_net()
    fn = "savetest.proto"
    weights = "savetest.caffemodel"
    with open(fn,"w") as fo:
        fo.write(str(net_str))
    net = caffe.Net(fn, caffe.TEST)
    net.params["conv1"][0].data[...] = 1
    net.save_hdf5(weights)
    net2 = caffe.Net(fn, weights, caffe.TEST)
    print(net.params["conv1"][0].data.sum())
    print(net2.params["conv1"][0].data.sum())

[BlGene]

@shelhamer while you are fixing hdf5, this was still on my mind.

[BlGene]

@erictzeng please review.

[BlGene]

@erictzeng the remaining build issues are sorted, please have a quick look now.

[erictzeng]

Sorry about the delay. It looks like there is a corresponding C function that can do this check:

https://support.hdfgroup.org/HDF5/doc/RM/RM_H5F.html#File-IsHDF5

Is there anything preventing us from using this call instead? That might save us from pulling in another dependency (though iirc it's bundled by default anyway, but still...)

[BlGene]

@erictzeng: I simplified to calling the C function.

Should the intention be to eventually switch to the c++ interface, or are there any reasons against this?

[erictzeng]

I don't think it'd be a bad idea to switch to the C++ interface.

The HDF5 snapshotting stuff uses the C interface because I was following the example set by the HDF5 data layers (just like this PR, where we're preferring the C interface to avoid pulling in another dep). Where possible, I think it's good to avoid mixing the two interfaces.

Clearly the C interface causes rather brittle code, though, so replacing it seems like a good move in my eyes.