chore: bump opensrv

[dantengsky]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Summary

The issue described in #16892, is caused by a read-after-use bug in the opersrv crate (ver 0.7).

Description:

Valgrind identifies that, during the connection establishment between the MariaDB JDBC client and Databend's MySQL service, memory freed by opensrv_mysql::packet_reader::PacketReader is being accessed, leading to the failure of MySQL connection establishment (failed to process the input MySQL protocol command correctly).

Resolution:

Fortunately, this issue has been fixed by @discord9 in PR #67. As a result, in this PR, the opensrv version used has been updated to commit #6cbb806 (and rustls has been bumped to version 0.23 to align with the version needed by opensrv)

Note:

To "reproduce" the following valgrind messages, Databend should be compiled using the standard memory allocator. Using the default jemalloc , valgrind can not detect any issues.

--1403874-- When reading debug info from /home/usr/workspace/fuse-query/target/debug/databend-query:
--1403874-- confused by the above DIE
==1403874== Warning: set address range perms: large range [0x7a8b000, 0x1e45e000) (defined)
==1403874== Thread 52 mysql-query-exe:
==1403874== Invalid read of size 1
==1403874==    at 0xCB0436A: core::cmp::impls::<impl core::cmp::PartialEq for u8>::ne (cmp.rs:1481)
==1403874==    by 0xCB04398: core::cmp::impls::<impl core::cmp::PartialEq<&B> for &A>::ne (cmp.rs:1665)
==1403874==    by 0xCB00909: <&[u8] as nom::traits::Compare<&[u8]>>::compare::{{closure}} (traits.rs:740)
==1403874==    by 0xCAFF860: core::iter::traits::iterator::Iterator::position::check::{{closure}} (iterator.rs:3055)
==1403874==    by 0xCAFF987: core::iter::traits::iterator::Iterator::try_fold (iterator.rs:2410)
==1403874==    by 0xCAFF7E6: core::iter::traits::iterator::Iterator::position (iterator.rs:3065)
==1403874==    by 0xCAFE103: nom::bytes::complete::tag::{{closure}} (traits.rs:740)
==1403874==    by 0xCAFFFE0: <F as nom::internal::Parser<I,O,E>>::parse (internal.rs:325)
==1403874==    by 0xCB03E60: nom::sequence::preceded::{{closure}} (mod.rs:72)
==1403874==    by 0xCB04490: <F as nom::internal::Parser<I,O,E>>::parse (internal.rs:325)
==1403874==    by 0xCAFBC48: nom::combinator::map::{{closure}} (mod.rs:79)
==1403874==    by 0xCAFD0D0: <F as nom::internal::Parser<I,O,E>>::parse (internal.rs:325)
==1403874==  Address 0x577556b4 is 4 bytes inside a block of size 4,096 free'd
==1403874==    at 0x2020427F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1403874==    by 0x7AE1053: <std::alloc::System as core::alloc::Allocator>::deallocate (alloc.rs:48)
==1403874==    by 0x7AE8577: <databend_common_base::mem_allocator::global::GlobalAllocator as core::alloc::global::GlobalAlloc>::dealloc (std_.rs:53)
==1403874==    by 0x7AED912: __rust_dealloc (ee_main.rs:35)
==1403874==    by 0x18FCF96C: <alloc::alloc::Global as core::alloc::Allocator>::deallocate (alloc.rs:119)
==1403874==    by 0x18FCFBCE: <alloc::raw_vec::RawVec<T,A> as core::ops::drop::Drop>::drop (raw_vec.rs:600)
==1403874==    by 0x18FCF4DA: core::ptr::drop_in_place<alloc::raw_vec::RawVec<u8>> (mod.rs:542)
==1403874==    by 0x18FCF473: core::ptr::drop_in_place<alloc::vec::Vec<u8>> (mod.rs:542)
==1403874==    by 0x8F7875F: opensrv_mysql::packet_reader::PacketReader<R>::next_async::{{closure}} (packet_reader.rs:138)
==1403874==    by 0xB05BA24: opensrv_mysql::AsyncMysqlIntermediary<B,R,W>::run::{{closure}} (lib.rs:562)
==1403874==    by 0x97EE0B0: opensrv_mysql::tls::plain_run_with_options::{{closure}} (tls.rs:57)
==1403874==    by 0x920F83F: databend_query::servers::mysql::mysql_session::MySQLConnection::run_on_stream::{{closure}}::{{closure}} (mysql_session.rs:92)
==1403874==  Block was alloc'd at
==1403874==    at 0x20201899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1403874==    by 0x7ADF339: std::sys::pal::unix::alloc::<impl core::alloc::global::GlobalAlloc for std::alloc::System>::alloc (alloc.rs:14)
==1403874==    by 0x7ADF55D: std::alloc::System::alloc_impl (alloc.rs:145)
==1403874==    by 0x7AE16A8: <std::alloc::System as core::alloc::Allocator>::allocate (alloc.rs:208)
==1403874==    by 0x7AE83D8: <databend_common_base::mem_allocator::global::GlobalAllocator as core::alloc::global::GlobalAlloc>::alloc (std_.rs:41)
==1403874==    by 0x7AED8B1: __rust_alloc (ee_main.rs:35)
==1403874==    by 0x1DB66D6A: alloc::alloc::alloc (alloc.rs:100)
==1403874==    by 0x1DB66EB0: alloc::alloc::Global::alloc_impl (alloc.rs:183)
==1403874==    by 0x1DB67E98: <alloc::alloc::Global as core::alloc::Allocator>::allocate (alloc.rs:243)
==1403874==    by 0x1DB6992A: alloc::raw_vec::finish_grow (raw_vec.rs:590)
==1403874==    by 0x1DB69E20: alloc::raw_vec::RawVec<T,A>::grow_amortized (raw_vec.rs:486)
==1403874==    by 0x1DB6A778: alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle (raw_vec.rs:349)

....

• related issue : bug: mariadb JDBC driver fails to connect #16892

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - manually tested

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is