Remove pending_payable_rowid column and the related processing

[bertllll]

(Planned in the second phase)

More description may be provided later.

This card was created to unload a good portion of work from GH-642 and pass it on separated. It bears on the pending_payable_rowid column in the payable table. This column becomes redundant as there are now different mechanisms which control if a new scan for payable should be run or rather prevented. It further stretches across the PayableDao trait, the method mark_pending_payable and all functions of similar name which also were left in the code yet.

The reason why this part was split off is that the payments will work even if this card isn't played yet and therefore not having to deal with this card could bring the whole-feature testing phase in less time. However, this card shouldn't be forgotten to be played because it implies a lot messy dead code staying in the codebase.

[utkarshg6]

I propose we link the payable table using tx_hash instead of rowid.

1. Linking Transactions: Use tx_hash to connect transactions in the payable table.

2. Handling Retries:

   • If a transaction needs to be retried, update the tx_hash of the retry transaction to the existing record.
   • Once the transaction is successful, delete the record.

3. Failed Retries:

   • If a retry fails and a new transaction is created, link the new tx_hash to the same record.

This approach will help us efficiently track transactions and their retries.

[bertllll]

I propose we link the payable table using tx_hash instead of rowid.

1. **Linking Transactions**: Use `tx_hash` to connect transactions in the payable table.

2. **Handling Retries**:
   
   * If a transaction needs to be retried, update the `tx_hash` of the retry transaction to the existing record.
   * Once the transaction is successful, delete the record.

3. **Failed Retries**:
   
   * If a retry fails and a new transaction is created, link the new `tx_hash` to the same record.

This approach will help us efficiently track transactions and their retries.

I'm sorry but I disagree. This efforts would cost time and energy despite it would produce just an overhead not helping anything. I have multiple arguments to explain why:

When we finalized the current design it occurred to me that it will always keep us from initiating a new batch of txs before we are done with those having been pending since last time. This is actually one of the fundamentals of this design and it makes me confident we can rely on this premise. Given that, one of the crucial purposes of this last column in the payable table, preventing creation of another tx, will lose its usecase. Thinking more about whether we could get rid of the column completely, and because I ran into the cluster of functions that served for marking the pending payable (that's basically what we used to call the operation) which had been a proved dev burden, I was actually happy to conclude that we can freely leave the responsibilities soaked in the scanner scheduling system, which can easily hold it, and the remaining purpose, to link the pending payable records with other tables, could be also treated differently, and again with certain benefits. From then on, I didn't doubt that we would want to unload the machinery and keep it more streamlined as long as we can and here we can do it.

This column should be considered from both the old and the new perspective which differ. It used to have a purpose. It allowed us to link records between the payable and pending_payable tables. You should know, however, what was the row in the latter table composed of. There was no parameter that could be used to link the record to the payable account.

We followed a kinda minimalist approach and did not include any unnecessary information. This changes drastically now. We are less efficient datawise now and are going to store much more than necessary. Therefore, even the receiver_address. It will be available in both tables and will be the easiest and most natural way to link these tables together. The JOIN statements we may need to implement will just require another where condition saying WHERE status LIKE 'Pending%'. But because there shouldn't be two pending txs from the same wallet, the linking element can be achieved by the wallet address, that's the first where clause.

We'd have to keep maintaining a code machinery that: a) can write this hash in (an isolated DAO operation), b) can remove it

Hashes are quite long and if we can avoid writing them (the more if the data would have just a temporary character in the payable_table) I'd like to take that chance.