Prepare a 2.2.7 patch release

[weiznich]

This PR prepares a 2.2.7 patch release.

It backports the following PR:

• Fix eq_any's nullability #4354
• Make NoOrderClause and OrderClause for third-party-backends #4387
• Generate InstrumentationEvent::BeginTransaction for custom transaction SQL #4393
• Bump pq-sys #4429
• Updated ipnetwork to 0.21 #4427
• DebugBinds/Query: Reduce monomorphization overhead #4417
• Bump rustversion to 1.83 and fix new clippy lints #4369 to fix the new warnings
• Auto type binary operators #4272
• Add support for joins to sub-joins to aliases #4281

I would like to release this on Friday 31.1.25

[Ten0]

LGTM and thanks! 😊

I would tend to also add #4281 as that's a minor upgrade that has zero chance to break existing stuff.

[weiznich]

I did some rather extensive CI debugging here as we had segfaults while running our sqlite tests. It turned out that this is caused by a bug in the libsqlite version shipped by ubuntu 24.04. See this bug report for some details: https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/2087772

Otherwise for anyone seeking to reproduce this:

The following rust code currently segfaults in libsqlite3 on ubuntu 24.04 with the libsqlite3-dev (sqlite 3.45.1) package installed.

use libsqlite3_sys as ffi;
use std::ffi::{CString, CStr};

const SQL: &str = "SELECT `users`.`id`, `users`.`name`, `users`.`hair_color`, `posts`.`id`, `posts`.`user_id`, `posts`.`title`, `posts`.`body`, `comments`.`id`, `comments`.`post_id`, `comments`.`text`, `likes`.`comment_id`, `likes`.`user_id`, `followings`.`user_id`, `followings`.`post_id`, `followings`.`email_notifications` FROM (`users` INNER JOIN ((`posts` LEFT OUTER JOIN (`comments` LEFT OUTER JOIN `likes` ON (`likes`.`comment_id` = `comments`.`id`)) ON (`comments`.`post_id` = `posts`.`id`)) LEFT OUTER JOIN `followings` ON (`followings`.`post_id` = `posts`.`id`)) ON (`posts`.`user_id` = `users`.`id`)) ORDER BY `users`.`id`, `posts`.`id`, `comments`.`id`";

fn main() {
    let url = CString::new("/tmp/test.db").unwrap();
    let mut conn_pointer = std::ptr::null_mut();
    let mut stmt = std::ptr::null_mut();
    let flags = ffi::SQLITE_OPEN_READWRITE;

    let sql = CString::new(SQL).unwrap();

    unsafe {
        let conn_status = ffi::sqlite3_open_v2(url.as_ptr(), &mut conn_pointer, flags, std::ptr::null());
        if conn_status != ffi::SQLITE_OK {
            panic!("Something went wrong");
        }

        let prep_result = ffi::sqlite3_prepare_v3(conn_pointer, sql.as_ptr(), SQL.len() as i32, 0, &mut stmt, std::ptr::null_mut());
        if prep_result != ffi::SQLITE_OK {
            let c_str = ffi::sqlite3_errmsg(conn_pointer);
            let c_str = CStr::from_ptr(c_str);
            println!("{}", c_str.to_string_lossy());

            panic!("Could not prepare");
        }

    }

    println!("Everything is fine");
}

It doesn't segfault if you manually build sqlite 3.45.1 and use that 😱