fix: ClientBuilder auth info drop before connect

[fMeow]

Issue description

The ClientBuilder is not properly tested and contains a severe memory leak issue.

The bugyy code is show below:

let fs = unsafe {
    let builder = hdfsNewBuilder();

    let name_node = CString::new(self.name_node.as_bytes())?;
    hdfsBuilderSetNameNode(builder, name_node.as_ptr());

    if let Some(v) = self.user {
        let user = CString::new(v.as_bytes())?;
        hdfsBuilderSetUserName(builder, user.as_ptr());  // DANGLING POINTER
        // user is dropped here, but hdfsBuilder still holds a pointer to it
    }

    if let Some(v) = self.kerberos_ticket_cache_path {
        let ticket_cache_path = CString::new(v.as_bytes())?;
        hdfsBuilderSetKerbTicketCachePath(builder, ticket_cache_path.as_ptr()); // DANGLING POINTER
        // ticket_cache_path is dropped here, but hdfsBuilder still holds a pointer to it
    }
   
    // now the user and ticket_cache_path are used to setup auth, but the underlying CString is already freed
    hdfsBuilderConnect(builder)
};

Solution

The solution is to declare a variable that lives until where hdfsBuilderConnect is called. Here I use MaybeUninit to hold the user and ticket_cache_path string when necessary. This raises (maybe or not) MSRV to 1.36.0, which is released in fall 2019.

What this PR does

• fix ClientBuilder::connect memory leak issue, properly set user and ticket_cache_path
• add a unit test to validate user declaration

[fMeow]

Please publish a patch release to crates.io under v0.3.1, and even better yank the previous v0.3.0.

The v0.3.0 provides no mean to properly declare user while the ClientBuilder::with_user() actually set a random non sense.

[fMeow]

The github action always use user runner as hdfs user. This is wierd. I test the same code on my local enveironment and it surely passed.

[Xuanwo]

The github action always use user runner as hdfs user. This is wierd. I test the same code on my local enveironment and it surely passed.

hdfs default namenode is backed by local fs, I'm guessing the returning user is also based on local fs's user too.

[fMeow]

I guess the username test should only run on cluster env.

[Xuanwo]

Thanks!