C API ownership problems

Version
Latest

Platform
All

Description
The docs for hyper_clientconn_handshake say "Both the io and the options are consumed in this function call." But the code looks like this:

    fn hyper_clientconn_handshake(io: *mut hyper_io, options: *mut hyper_clientconn_options) -> *mut hyper_task {
        let options = non_null! { Box::from_raw(options) ?= ptr::null_mut() };
        let io = non_null! { Box::from_raw(io) ?= ptr::null_mut() };

If options is null the function won't take ownership of io, which has a high chance of causing a memory leak. Probably Box::from_raw should be called on both arguments before they are checked for null?

Similarly, the docs for hyper_executor_push say "The executor takes ownership of the task, it should not be accessed
again unless returned back to the user with hyper_executor_poll." But the code does this:

    fn hyper_executor_push(exec: *const hyper_executor, task: *mut hyper_task) -> hyper_code {
        let exec = non_null!(&*exec ?= hyper_code::HYPERE_INVALID_ARG);
        let task = non_null!(Box::from_raw(task) ?= hyper_code::HYPERE_INVALID_ARG);

If exec is null the function won't take ownership of task, which also is likely to result in memory leaks. In this case the two lines could be swapped to fix the problem.

I'm happy to file a PR fixing these if it seems like I've diagnosed the situation correctly. I looked through all the other C API functions and these were the only two cases like this I could find.

Start at the hyper_clientconn_handshake and hyper_executor_push entry points shown in the issue, then trace their null-argument and ownership paths. Compare the behavior with each function's ownership documentation and verify that the documented consumption guarantees hold for invalid arguments. Done means both code paths and their docs agree without leaving an owned argument unhandled.