refactor: remove non-test sqlx macro usage

[djordon]

Description

Addresses part of #411.

There are a number of paths that can address the linked issue. The path taken here is to remove our sqlx macro usage. Thing is, this PR doesn't complete remove our macro usage, since we still use it for tests. Once we remove our macro usage in tests then we can easily bump our stacks core dependency. I went this path partly because it allowed for a few simplifications in the code base.

Like #436, this was done because I needed something mentally simple to work on in transit.

Changes

• Remove sqlx macro usage outside of integration test setup.
• Remove the sqlx-cli as a quasi- dev requirement.
• Make amount and max_fee types u64s. This is possible because we aren't using the sqlx macros for our queries.

The following are the more questionable changes

• Make thresholds, and num_signers integers u16 types. I think that we'll have other issues if these numbers are greater than a few hundred in practice, so u16 seems fine.
• Make the context window type a u16 too. This will usually be much less than the expected number of bitcoin blocks in a year, so a u16 is fine. But maybe it's better for a u32 here instead.
• Changing the type signature of the DbRead and DbWrite traits. I don't feel too strongly about the change but it allows for things to be much simpler as well.

My apologies to @netrome for removing our sqlx macro usage.

Testing Information

If tests pass then this is probably fine. I should also check the the values in the postgres implementations of the DbRead and DbWrite trait functions. Right now I just do naked as casts, which is not strictly correct, but very likely fine in practice. I'll probably change it later.

Checklist:

• I have performed a self-review of my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[AshtonStephens]

LGTM.

[AshtonStephens]

I'm okay with changing this to u16 because I don't perceive much risk of there being 65535 signers.

[djordon]

Yeah, we'd also have to change the smart contracts -- or discontinue noting an accurate signer bitmap on chain -- if there were more than 128 signers.

[AshtonStephens]

What do you think of doing the decomposition up front?

        let model::DepositRequest {
            txid,
            output_index,
            spend_script,
            reclaim_script,
            recipient: _,
            amount,
            max_fee,
            sender_addresses: _,
        } = request;

        let txid = bitcoin::Txid::from_byte_array(
            txid.try_into().map_err(|_| Error::TypeConversion)?,
        );
        let vout = output_index;

        let signer_bitmap = BitArray::ZERO; // TODO(326): Populate

        Ok(Self {
            outpoint: OutPoint { txid, vout },
            max_fee,
            signer_bitmap,
            amount,
            deposit_script: ScriptBuf::from_bytes(spend_script),
            reclaim_script: ScriptBuf::from_bytes(reclaim_script),
            signers_public_key,
        })

I'm mostly curious, you don't have to do this. Same applies to the other function that does something similar.

[djordon]

I find the approach that does not do the decomposition a little easier to read. That's because I only need to look at the lines in return type to see what values were set to any particular field (assuming request is immutable). Under the decomposition approach, there might be some intermediate change to a variable that I need to look out for. Also, the non-decomposition approach is fewer lines of code and doesn't seem much more complex. But the destructuring done in this example is easy enough to read so I wouldn't sweat it if I were reviewing.

Anyway, I think that's the general "principle" for me when I'm writing code. It's not set in stone for me, so I'm also curious about how you (and others) think about this.

[AshtonStephens]

Whereever possible I see amount: request.amount and want to see it be just amount. That said, I actually do agree with your position, I was just curious what you thought.

[AshtonStephens]

Saw the two new changes. They look good to me.