feat: Unify Debug implementations across PgRow, MySqlRow and SqliteRow

[davidcornu]

Context

In a personal code base I currently maintain a Row implementation called DebugRow as a catch-all type for queries so that I can use its Debug implementation for snapshot testing (using the great insta crate).

While upgrading the version of sqlx I noticed there was now a useful Debug implementation for PgRow (#2917) which had me hoping there was an equivalent for SqliteRow, but after digging through the code I found out

• PgRow has a custom Debug which prints out the contents of the row using debug_map()
• MySqlRow uses a derived Debug
• SqliteRow does not implement Debug

Rather than implement similar logic to PgRow for SqliteRow I figured it might be better to unify the implementations as the various traits (e.g. Row, Database, TypeChecking) provide everything needed to implement PgRow's version generically.

Also related: #150

Proposed changes

1. Introduce a new sqlx_core::row::debug_row function
2. Use (1) to implement Debug on SqliteRow
3. Use (1) to replace PgRow's Debug implementation
4. Use (1) to replace MySqlRow's derived Debug

Is this a breaking change?

Yes.

1. PgRow's Debug implementation changes a little bit because of the use of std::any::type_name
   (This could be avoided by passing a name to debug_row instead but is definitely less elegant)
2. MySqlRow's Debug implementation would be completely different

If this is too ambitious of a change I'm happy to pare it down to just the SqliteRow change as that's fundamentally what I'm after.

[abonander]

This actually shouldn't be considered a breaking change because the Debug output of a type should generally not be considered to be stable. It's right there in the name: it's meant for debugging, not necessarily something to be depended upon in production.

The only time the change of Debug output should be considered a breaking change is if it's explicitly promised to be stable.

[davidcornu]

This actually shouldn't be considered a breaking change because the Debug output of a type should generally not be considered to be stable. It's right there in the name: it's meant for debugging, not necessarily something to be depended upon in production.

The only time the change of Debug output should be considered a breaking change is if it's explicitly promised to be stable.

Agreed in principle. My thinking was that it'd be a bit of an inconvenience if folks were using debug snapshots in their test suites and would now have to audit and commit all the changes. Not the end of the world though.