In internal transactions, we can have a payment line where source is using a bank account and destination is using another bank account.
Bank Reconciliation did not support these lines properly, because it simply assumed that "if there's a bank reconciliation on this line, it means the line is reconciled", but this was incorrect, because source and destination needs to be able to reconcile this line independently.
The fixes is to change the rule from "if there's a bank reconciliation on this line, it means the line is reconciled" to "if there's a bank reconciliation with the same bank account as this line's source payment, it means the line is reconciled for source" and "if there's a bank reconciliation with the same bank account as this line's destination payment, it means the line is reconciled for destination".
The related key used to select the already reconciled lines or lines to reconcile becomes a bit more complex, it joins with category table to ensure the bank reconciliation's bank account (which is source_payment on the bank reconciliation) is the same as the section_uid of the line in stock table that we are considering. This also has a side effect that this related key only work with queries on stock table, but it was never intended to be used elsewhere.
Another problem is that queries made by bank reconciliation module become a bit more slower. For sites where this is a problem, the recommended approach is to replace the related keys by columns on stock table. In cfec8d2b (which is part of this MR) we add indexation methods. In 5afb0020 (which is not part of this MR and not planned for inclusion in "default" ERP5) we show an example of how to enable these methods to actually add the columns in stock table.