Fix transfer combine set_rgb_consumer call

[zoedberg]

This PR fixes the call to set_rgb_consumer that was provided with the incorrect contract ID.

Moreover I would like to report 2 issues that are related to the same method, TransferCommand::Combine.

Let me know if you prefer me to open dedicated issues or if we should tackle them in the context of this PR.

---

First, let blank_bundle = TransitionBundle::blank(&outpoint_map, &bmap! {})?; will always receive a NoOutpoint error, since the TransitionBundle::blank method expects to find at least an outpoint in it:

let (op, close_method) = new_outpoints
    .get(&input.ty)
    .ok_or(Error::NoOutpoint(input.ty))?;

Should we add this map of new outpoints as a CLI parameter or should we reuse the change outpoint that we should be able to get from the provided transition?

---

Second, in

let blank_bundle = TransitionBundle::blank(&outpoint_map, &bmap! {})?;
for (transition, indexes) in blank_bundle.revealed_iter() {
    psbt.push_rgb_transition(transition.clone())?;
    for no in indexes {
        psbt.inputs[*no as usize]
            .set_rgb_consumer(cid, transition.node_id())?;
    }
}

psbt.inputs[*no as usize] can sometimes fail depending on the input outpoint vout value and the number of psbt inputs. This happens because no is the vout of an outpoint, which is not the position of the outpoint in the psbt.inputs vector:

fn blank(
    prev_state: &BTreeMap<OutPoint, BTreeSet<OutpointState>>,
    new_outpoints: &BTreeMap<OwnedRightType, (OutPoint, CloseMethod)>,
) -> Result<TransitionBundle, Error> {
    let mut transitions: BTreeMap<Transition, BTreeSet<u16>> = bmap! {};

    for (tx_outpoint, inputs) in prev_state {
        // [...]
        transitions.insert(transition, bset! { tx_outpoint.vout as u16 });
    }

    TransitionBundle::try_from(transitions).map_err(Error::from)
}

[dr-orlovsky]

ACK 007fb1d

[dr-orlovsky]

Let me know if you prefer me to open dedicated issues or if we should tackle them in the context of this PR.

Yes, that is the best way for now and the future, otherwise we will loose track on them once the PR with fix is merged (like I did now)

[dr-orlovsky]

... and yes, both reported issues seems to be bugs requiring fixes.

Should we add this map of new outpoints as a CLI parameter or should we reuse the change outpoint that we should be able to get from the provided transition?

I think both: allow to specify new UTXOs via CLI - and failback to the change if they are not provided