Fix "requires that 'r must outlive 'static"

[bewee-i]

When building the following on nightly

#[derive(sqlx::Type)]
struct Foobar {
    a: String,
}

Compilation fails with

error: lifetime may not live long enough
  --> tests/foo.rs:1:10
   |
5  | #[derive(sqlx::Type)]
   |          ^^^^^^^^^^
   |          |
   |          lifetime `'r` defined here
   |          requires that `'r` must outlive `'static`
   |
note: due to current limitations in the borrow checker, this implies a `'static` lifetime
  --> /home/b/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sqlx-core-0.6.3/src/postgres/types/record.rs:97:12
   |
97 |         T: for<'a> Decode<'a, Postgres> + Type<Postgres>,
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: this error originates in the derive macro `sqlx::Type` (in Nightly builds, run with -Z macro-backtrace for more info)

error: implementation of `sqlx::Decode` is not general enough
 --> tests/foo.rs:5:10
  |
5 | #[derive(sqlx::Type)]
  |          ^^^^^^^^^^ implementation of `sqlx::Decode` is not general enough
  |
  = note: `std::string::String` must implement `sqlx::Decode<'0, Postgres>`, for any lifetime `'0`...
  = note: ...but it actually implements `sqlx::Decode<'1, Postgres>`, for some specific lifetime `'1`
  = note: this error originates in the derive macro `sqlx::Type` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `foo` (test "foo") due to 2 previous errors

To quick-fix this in our project, we resorted to expanding the code generated by sqlx::Type and manually applying the fix that this PR now proposes to implement in the macro.

The changes are not tested yet, but I could invest some additional effort if you can guide me.

[joelawm]

Awesome work! Does this fix?

#[derive(sqlx::Type)]
pub struct Foo {
    pub barz: i32,
    pub bars: String,
    pub bara: Option<String>
}

Many other people have tried providing fixes and composite types in Postgres can return null and this is directly related.

[bewee-i]

@joelawm Yep, that one seems to be fixed as well

[joelawm]

@bewee-i Amazing work! @abonander will probably tell you to create some Tests proving that it can handle yours and my example. This could also close out some other existing PR's that seem to be more complicated. I myself will also be testing this locally since I need a similar fix for this, so I will post when I have some basic E2E local tests working.

[bewee-i]

Hey @joelawm @abonander, any concrete updates on what is required from my end to make this ready?

[abonander]

Superceded by #2940