Potential deadlock invoking Session::refresh_metadata_callback

[tedyu]

Here is sample stack trace:

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f4a1c0afbb5 in __GI___pthread_mutex_lock (mutex=0x1fe7328) at ../nptl/pthread_mutex_lock.c:80
#2  0x00007f4a1b5a5899 in uv_mutex_lock () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#3  0x000000000095d8fc in cass::Session::refresh_metadata_callback(CassFuture_*, void*) ()
#4  0x000000000094bb3c in cass::Future::internal_set(cass::ScopedLock<cass::Mutex>&) ()
#5  0x00000000009eebcc in cass::RequestHandler::set_error(CassError_, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#6  0x0000000000957c43 in cass::Session::execute(cass::SharedRefPtr<cass::RequestHandler> const&) ()
#7  0x000000000095dddd in cass::Session::on_refresh_metadata(cass::PeriodicTask*) ()
#8  0x00007f4a1b5969b4 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#9  0x00007f4a1c0ad4a4 in start_thread (arg=0x7f49f9ffe700) at pthread_create.c:456

In the Session::on_refresh_metadata(), we already take the lock on refresh_metadata_future_mutex_.
We shouldn't take lock on refresh_metadata_future_mutex_ again in Session::refresh_metadata_callback