romio info: letting romio keep its internal setup

[markalle]

I'm restoring the info function pointers to the IO module
but allowing the function pointers to be NULL (eg in ompio).
And letting romio321 set its function pointers for those
routines.

This means the info system uses the new OMPI-level info
system for most things, but skips it and uses the pre-existing
romio info system just for the romio module.

It's possible to convert romio, but I went a ways down that
path and found it kind of convoluted. Having pointers from
the lower level ADIO_File back to the higher level ompi_file_t
wasn't too bad, but I got stuck trying to figure out where/how
to register the infosubscribe_subscribe callbacks vs the way
initial k/v values are scattered around the romio code currently.

Signed-off-by: Mark Allen [email protected]

[markalle]

Without this PR the romio info system is still used internally, info key/values are set and used from things like ROMIO_HINTS=file, but if the user queries with MPI_File_get_info() they don't see anything because all the ROMIO info is internally using their old fd->info setup while the higher level MPI calls are using the new OMPI-level info system.

[edgargabriel]

@markalle what is your plan with this pr, do you plan to commit it? The reason I ask is because I think a user tapped into exactly this problem, see issue

#6921

[markalle]

Yeah, I still want to get this in. Geoffrey mentioned it might have bitrotted between my initial submittal and now so let me check that. But overall I think this is a good commit that we should pull in

[markalle]

Okay, nothing needed changed, geoffrey just wanted it rebased against master since it had been sitting around for a while

[markalle]

@hppritcha is the cray_cle failure real?

[jsquyres]

@markalle You can make the "Pull Request Build Checker" run again like this:

bot:ompi:retest