backport: Merge #23517,23546,23703 (scripted diff)

[vijaydasmp]

-BEGIN VERIFY SCRIPT-
git grep -l GetArg | xargs sed -i 's/GetArg(([^)]*( [0-9]+|-1|port|BaseParams().RPCPort()|Params().GetDefaultPort()|_TIMEOUT|Height|_WORKQUEUE|_THREADS|_CONNECTIONS|LIMIT|SigOp|Bytes|_VERSION|_AGE|_CHECKS|Checks() ? 1 :
0|_BANTIME|Cache|BLOCKS|LEVEL|Weight|Version|BUFFER|TARGET|WEIGHT|TXN|TRANSACTIONS|ADJUSTMENT|i64|Size|nDefault|_EXPIRY|HEIGHT|SIZE|SNDHWM|_TIME_MS)))/GetIntArg(\1)/g'
-END VERIFY SCRIPT-

[github-actions]

This pull request has conflicts, please rebase.

[knst]

I feel like it is not good idea for rushing with backports such as "merge bitcoin#22976: Rename overloaded int GetArg to GetIntArg"

By rough estimation, there are more than 500 older backports waiting their turn to be done and any backport from that queue that uses an old version of GetArg will create an extra conflict that requires manual resolving.

Of course, each particular fix in each particular case is trivial, the compiler even will show it as a compilation error, so, it won't cause any real issue.

But disadvantage of doing bitcoin#22976 at this moment is an overall slowdown of backporting process. Current backport status of full coverage (98-99%) at this point in v21:

Q_Staged (merged to knstqq local repo) ae32e5c Merge bitcoin#18669: log: Use Join() helper when listing log categories FALSE 8/21/2023 3 3 FALSE

If get list all of commit between them 22976 and 18669:

 git rev-list --ancestry-path ae32e5ce3d..825f4a64e612dab62cd0a73b2afe32dac5e0c69f

and grep 'GetArg' after that:

git rev-list --ancestry-path ae32e5ce3d..825f4a64e612dab62cd0a73b2afe32dac5e0c69f^ | xargs git show  | grep "\<GetArg\>"  | grep '^[+-]' -c
477

There's 477 particular usage of GetArg and even assuming that 50% of this changes are already backported, it is still huge amount.

It means that all trivial changes such as this https://github.com/bitcoin/bitcoin/pull/21056/files

+    const int timeout = gArgs.GetArg("-rpcwaittimeout", DEFAULT_WAIT_CLIENT_TIMEOUT);
+    const int64_t deadline = GetTime<std::chrono::seconds>().count() + timeout;

will require one extra manual conflict resolving/compilation fix.

@vijaydasmp may I ask you to don't backports any big refactorings such as this one (especially scripted-diffs that affect hundreds of lines) from v22 or newer bitcoin version while the gap is that big yet?

[vijaydasmp]

I feel like it is not good idea for rushing with backports such as "merge bitcoin#22976: Rename overloaded int GetArg to GetIntArg"

By rough estimation, there are more than 500 older backports waiting their turn to be done and any backport from that queue that uses an old version of GetArg will create an extra conflict that requires manual resolving.

Of course, each particular fix in each particular case is trivial, the compiler even will show it as a compilation error, so, it won't cause any real issue.

But disadvantage of doing bitcoin#22976 at this moment is an overall slowdown of backporting process. Current backport status of full coverage (98-99%) at this point in v21:

Q_Staged (merged to knstqq local repo) ae32e5c Merge bitcoin#18669: log: Use Join() helper when listing log categories FALSE 8/21/2023 3 3 FALSE

If get list all of commit between them 22976 and 18669:

 git rev-list --ancestry-path ae32e5ce3d..825f4a64e612dab62cd0a73b2afe32dac5e0c69f

and grep 'GetArg' after that:

git rev-list --ancestry-path ae32e5ce3d..825f4a64e612dab62cd0a73b2afe32dac5e0c69f^ | xargs git show  | grep "\<GetArg\>"  | grep '^[+-]' -c
477

There's 477 particular usage of GetArg and even assuming that 50% of this changes are already backported, it is still huge amount.

It means that all trivial changes such as this https://github.com/bitcoin/bitcoin/pull/21056/files

+    const int timeout = gArgs.GetArg("-rpcwaittimeout", DEFAULT_WAIT_CLIENT_TIMEOUT);
+    const int64_t deadline = GetTime<std::chrono::seconds>().count() + timeout;

will require one extra manual conflict resolving/compilation fix.

@vijaydasmp may I ask you to don't backports any big refactorings such as this one (especially scripted-diffs that affect hundreds of lines) from v22 or newer bitcoin version while the gap is that big yet?

Thanks I will drop this commit for now, will make use of above command to efficiently backport

[vijaydasmp]

will be keeping this scripted diff in drafts only and will open it for review once its appropriate for it to merge

[github-actions]

This pull request has conflicts, please rebase.