Add ancestor_bump_fee to Candidate

[aagbotemi]

Description

Add ancestor_bump_fee field to Candidate, allowing callers to
express the additional fee a child transaction must pay to bring
its unconfirmed ancestors up to the target feerate.

Note to Reviewers

Cross-candidate ancestor deduplication is not handled at this layer.
Shared ancestors across candidates are counted per-candidate, which
may overcount when multiple selected candidates share an ancestor.
This is conservative (overpays, never underpays). The wallet layer
deduplicates post-selection.

Closes #24

Changelog notice

• Added ancestor_bump_fee field to Candidate for ancestor-aware coin selection

Checklists

All Submissions:

• I followed the contribution guidelines
• I've added tests for the new feature
• I've added docs for the new feature
• I'm linking the issue being fixed by this PR

[evanlinjin]

NACK

Thanks for working on this. However, this solution is flawed.

• ancestor_bump_fee is a function of the target feerate. This is incorrect as Candidate should only have fixed properties of an UTXO.
• This solution does not take ancestor overlaps into account. Please refer to #24 (comment)

Also, next time, please remember to reference pre-existing PRs addressing similar problems. This PR is essentially a competing solution to #38.

[aagbotemi]

Thanks for the review.

• ancestor_bump_fee is a function of the target feerate. This is incorrect as Candidate should only have fixed properties of an UTXO.
• This solution does not take ancestor overlaps into account. Please refer to CPFP: Allow telling coin selector that a candidate has unconfirmed parents #24 (comment)

Both points are valid.

Also, next time, please remember to reference pre-existing PRs addressing similar problems. This PR is essentially a competing solution to #38.

I looked at #38 before opening this PR and concluded they addressed different layers. #38 operates at the transaction level with a single Package aggregate, this PR at the candidate level. I should have commented on #38 explaining this reasoning rather than opening a separate PR.

[aagbotemi]

Closing in favor of #43