Update to sqlx 0.8.6

[pronebird]

Sqlx updates have been painful and we should strive keeping it fresh to reduce amount of efforts needed for upgrade. But also due to RUSTSEC-2024-0363 which may or may not be affecting us, but still, we should consider upgrading. In part I am looking to update sqlx because we want fresh copy of it in nym-vpn-client but also because I hold a belief that perhaps one of those updates will fix some of the issues with sql databases that we witnessed on Windows.

Please inspect and test this upgrade carefully because there have been a few critical changes in sqlx:

1. COUNT queries return i64 instead of i32 which seems sensible
2. query_as no longer understands COALESCE and fails to compile when it spots nullable field
3. Conversations between Option<OffsetDateTime> and Option<chrono::DateTime> aren't available, so I had to switch from chrono::NaiveDateTime to OffsetDateTime in one occurrence to circumvent that. However the code looks nicer to due to present From traits between SystemTime and OffsetDateTime. I assume there is no difference functionally. Going forward, my suggestion would be to replace time with chrono which should reduce some frictions in sqlx as it seems like it decides to use OffsetDateTime for WireguardPeer struct despite sqlx::types::chrono::NaiveDateTime being defined for last_handshake
4. fetch_one no longer returns Option<T> but T

Connected issue: JIRA-VPN-3456

---

This change is 

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nym-explorer-v2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 30, 2025 8:21am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
docs-nextra	⬜️ Ignored (Inspect)	Visit Preview		May 30, 2025 8:21am
nym-next-explorer	⬜️ Ignored (Inspect)	Visit Preview		May 30, 2025 8:21am

[simonwicky]

Going forward, my suggestion would be to replace time with chrono

IIRC, we use time almost everywhere, chrono might be the easier to replace. From my statistics API adventures, I also read that while sqlx 0.7 preferred chrono over time when both features were enabled, it was the opposite in sqlx 0.8. (although I didn't test it). It might then be worth to replace chrono for time

[pronebird]

Going forward, my suggestion would be to replace time with chrono

IIRC, we use time almost everywhere, chrono might be the easier to replace. From my statistics API adventures, I also read that while sqlx 0.7 preferred chrono over time when both features were enabled, it was the opposite in sqlx 0.8. (although I didn't test it). It might then be worth to replace chrono for time

I see the same behaviour hence changed chrono to time although I prefer chrono mostly because I am used to it.

[jstuczyn]

Going forward, my suggestion would be to replace time with chrono

I'm not a fan of this - we're using time almost everywhere apart from a single place. if anything we should purge chrono in favour of time imo

[pronebird]

@benedettadavico can you check the milestone for this please?