Don't use hard-coded AllowFree, as this is usually far too low. #6997

Try to find a better estimate for the priority needed for a free transaction within the next few confirmation targets, or just fall back to add a fee if unsuccessful.

Something similar should probably be done with the default fee, since the default is usually much lower than what estimatefee 2 recommends if estimatefee 1 fails. On the other hand estimatefee usually recommends a much higher fee than actually required for the confirmation target, and this may lead to artificial fee inflation. When a transaction using the recommended fee/priority doesn't go through in the first block, there is usually something else, e.g. individual miner policy, preventing it.

This logic is already included in a more complete way in #6134 (which replaced #6131)

@morcos Correct, however your latest commit in #6134 depends on, and tries to work around the current mempool trimming bug in a way that only works for one special case. A better approach would be to fix mempool trimming by making it aware of priority. (As long as priority is a supported concept, if not priority should be removed entirely, not by introducing bugs to make it fail.)

@laanwj this can be closed now that #6134 is merged

Superseded by #6134. Closing.