fix: wallet coin selection respects max_block_weight

[i1skn]

Deprecate "soft" max_outputs limit and introduce "hard" max_outputs
limit based on max_block_weight. Should fix #2510

[ignopeverell]

Looks like this introduces some bona fide test compilation failures.

[i1skn]

@ignopeverell my fault, fixed!

[ignopeverell]

Apologies if this is a misunderstanding, I'm not too familiar with this code. But shouldn't you calculate the max number of inputs for change_outputs + 1 to account for the receiver's output?

[i1skn]

This is correct, but first, we need to understand do we need a change. First, we calculate assuming that there will be no change (this gives us also the lowest fee). We check do we have fee+amount on our balance or not and only then we figure out do we need a change output or we can transfer without it.
If we need one - we set:

grin/wallet/src/libwallet/internal/selection.rs

Line 301 in 6a6a423

let num_outputs = change_outputs + 1;

and then select coins using num_outputs

grin/wallet/src/libwallet/internal/selection.rs

Lines 322 to 330 in 6a6a423

	coins = select_coins(
	wallet,
	amount_with_fee,
	current_height,
	minimum_confirmations,
	calculate_max_inputs_in_block(num_outputs),
	selection_strategy_is_use_all,
	parent_key_id,
	)

At least that's how I get it, probably @yeastplume can verify does this make sense or not.

[yeastplume]

Yes, correct, that's what happens.

[yeastplume]

LGTM, but merge conflict introduced, sorry.

I think I'm okay with removing the concept of a manually specifiable max_outputs in the name of reducing the exposed complexity.