[stable2412] Backport #6540

[paritytech-release-backport-bot]

Backport #6540 into stable2412 from Ank4n.

See the documentation on how to use this bot.

[paritytech-release-backport-bot]

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-6540-to-stable2412
git worktree add --checkout .worktree/backport-6540-to-stable2412 backport-6540-to-stable2412
cd .worktree/backport-6540-to-stable2412
git reset --hard HEAD^
git cherry-pick -x bf20a9ee18f7215210bbbabf79e955c8c35b3360
git push --force-with-lease

[github-actions]

This pull request is amending an existing release. Please proceed with extreme caution,
as to not impact downstream teams that rely on the stability of it. Some things to consider:

• Backports are only for 'patch' or 'minor' changes. No 'major' or other breaking change.
• Should be a legit fix for some bug, not adding tons of new features.
• Must either be already audited or not need an audit.

Emergency Bypass

If you really need to bypass this check: add validate: false to each crate
in the Prdoc where a breaking change is introduced. This will release a new major
version of that crate and all its reverse dependencies and basically break the release.

[Ank4n]

This is a breaking change, but we have already backported this to 2407 and 2409, so probably better keep it that way.

[EgorPopelyaev]

@Ank4n @bkontur this pr has a major bump

[Ank4n]

@Ank4n @bkontur this pr has a major bump

Re: #8355 (comment)

I could make this non-breaking (by reusing an existing error), but given that the same breaking change has already been applied on the backport to stable2409, I think it would be pointless.

[EgorPopelyaev]

I see that in those backports the changes were backported as patch, was it done by mistake?

[EgorPopelyaev]

Also, I think it wouldn't be pointless, as we won't break one more release, which is in use at the moment

[ggwpez]

Major bumps in backports are not permissible anymore. They messed up 2503 and we dont want to mess up any more releases because of them...
There is some rational explained here https://forum.parity.io/t/stable-releases/2142/48

[Ank4n]

@ggwpez @EgorPopelyaev
The breaking change here is the introduction of a new error. I can rework this PR to avoid adding a new error and make it non-breaking if needed.

However, the same new error has already been introduced in the backport to stable2409, so not including it here would technically be a breaking change relative to that.

The logic change itself is quite small (under 10 LOC), along with some tests and updated rustdocs.
This patch addresses a potential low- to mid-severity security issue, preventing a feeless transactions from being triggered with very small values.

P.S.: I am happy to comply based on your preference, just trying to understand the best path forward.

[EgorPopelyaev]

I would go for changing it to not break this release