Add logging and improve counting of amendment votes from UNL

[ximinez]

High Level Overview of Change

Adds debug-level logging of the amendment vote counting and decision making process. Also, tweaks the way the vote threshold is computed to only account for validators that the node has votes for, whether fresh or cached.

Context of Change

Some UNL validators were not reflecting an accurate count of the total votes for given amendments. (The problem seemed to resolve itself when the node restarted.) This made it look like the amendment did not have 80% majority, when it actually did. The situation did not resolve itself until the vote count increased again.

Because this processing was completely transparent, there was no way to tell why the votes were inaccurate, and because restarting seemed to fix the issue, it couldn't be reproduced with modified code.

Despite appearances, this issue is not security sensitive because

1. It can only delay acceptance of an amendment
2. It can not force an amendment to be accepted prematurely
3. There is a workaround

While adding logging, I noticed and fixed a possible bug in the way that the total validations are counted, which affects the way the threshold is computed. Even with this fixed, though, it doesn't explain why the counts are off.

The primary purpose of this change / PR is to have logging available in case something like this ever happens again.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change that only restructures code)

Test Plan

• Set log_level for Amendments and LedgerConsensus to debug or trace.
• After a flag ledger, search the debug log for the name and/or hash of the amendment of interest. Or just search for Amendment:.
• There will be a lot more logs than before.

[codecov]

Codecov Report

Attention: Patch coverage is 90.14085% with 7 lines in your changes missing coverage. Please review.

Project coverage is 78.2%. Comparing base (0968cdf) to head (f7c01e7).

Files with missing lines	Patch %	Lines
src/xrpld/app/misc/detail/AmendmentTable.cpp	89.7%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5173     +/-   ##
=========================================
+ Coverage     78.1%   78.2%   +0.1%     
=========================================
  Files          790     790             
  Lines        67623   67676     +53     
  Branches      8163    8149     -14     
=========================================
+ Hits         52846   52927     +81     
+ Misses       14777   14749     -28     

Files with missing lines	Coverage Δ
src/xrpld/app/consensus/RCLConsensus.cpp	65.4% <ø> (ø)
src/xrpld/app/misc/AmendmentTable.h	100.0% <100.0%> (ø)
src/xrpld/app/misc/detail/AmendmentTable.cpp	95.5% <89.7%> (-1.4%)	⬇️

... and 7 files with indirect coverage changes

[vlntb]

Happy to approve once my comment is answered.

[vlntb]

[nit] There is no real need to use streams here. We should move to using more modern and concise std::format in such cases.

auto message = std::format("{} ({}) has {} votes", 
                           entry.first, 
                           entry.second.name, 
                           vote->votes(entry.first));

[ximinez]

We use streams everywhere else we build strings this way. I don't see any instances of std::format. I don't object to starting this change process, but I can't promise it'll catch on.

[ximinez]

Actually, this didn't work on my end. I think std::format doesn't like the unit256 type. I can look more into it later.

[vlntb]

I agree that this is much clearer and safer, than using NetClock::time_point::max

[vlntb]

LGTM