gui: Initial implementation of GUI MRC submission form

[jamescowens]

This is the initial implementation of the GUI submission form, implemented mainly in mrcmodel.h/cpp and mrcrequestpage.h/cpp/ui. Note that it is from my mrc_wizard branch, which in turn is based on the mrc branch, so this PR will show the mrc branch commits until the latest mrc PR is merged and the mrc_wizard branch is rebased [done].

As of 5/16/2022 this is a fully functional MRC submission screen. It is currently accessed by a tool button next to the researcher "gear" button on the main screen that is visible ONLY if the wallet is in solo mode, the researcher has a valid beacon, and the wallet is in sync.

The screen looks like this:

(This picture shows the screen in the state where an error is displayed that it is too soon since the last payment, as a tooltip.)

The PR touches several other areas to provide minor extensions, and in the case of the rpc function createmrcrequests, bug fixes on the queue head/tail calculation, and implementation of the pay limit fee calculation, which in the case of where the queue is oversubscribed (i.e. the number of MRCs in the memory pool exceeds the maximum that can be paid out in a block), provides the fee paid by the last MRC in the queue sorted by fee (which is the last one that will be paid by the miner). This is the minimum hurdle to get over when fee boosting to displace the last entry in the pay limit and take over the last slot.

The model and page have implemented full signaling from the core of state changes that affect MRC status to allow automatic updating of the screen without having to push the "update" button. (In fact, the update button may be removed soon, as it is probably not necessary anymore.) Note this also has the advantage that the MRC request page responds correctly to actions taken by the local node core (or other nodes) as they come across the network. For example if the local node owner has the MRC request screen open and decides to submit an MRC via the debug console or rpc createmrcrequest, if the request is successful, the MRC request screen will reflect the submission in real time as if the MRC submit screen were used.

If an MRC cannot be submitted, the triangular error icon will be displayed (with an appropriate tooltip) and the submit button will be disabled. The error conditions can be seen very easily by looking at MRCModel::refresh() and MRCModel::submitMRC().

See in MRCModel.h

enum class MRCRequestStatus
{
NONE,
ELIGIBLE,
NOT_VALID_RESEARCHER,
CREATE_ERROR,
PENDING,
QUEUE_FULL,
PENDING_CANCEL,
STALE_CANCEL,
ZERO_PAYOUT,
EXCESSIVE_FEE,
WALLET_LOCKED,
SUBMIT_ERROR
};

also see

enum ModelStatus {
    VALID,
    NOT_VALID_RESEARCHER,
    INVALID_BLOCK_VERSION,
    OUT_OF_SYNC,
    NO_BLOCK_UPDATE_FROM_INIT
};

So everything except for NONE and ELIGIBLE in MRCRequestStatus is considered an error state. The handling of "PENDING", however, is specialized, as this means that a new MRC cannot be submitted while there is an existing MRC already (submitted) in the memory pool.

The handling of QUEUE_FULL, PENDING_CANCEL, and STALE_CANCEL are also specialized and represent special handling for corner cases given the MRC submission and payment model implemented in protocol. In the case of QUEUE_FULL, this represents where the number of MRCs in the memory pool is at the output (pay) limit, in which case the submit button is disabled and an error triangle appears suggesting that the user boost the fees if desired to try to slot in and push another MRC down. The PENDING_CANCEL represents the inverse condition from that just described, which is that the user had successfully submitted an MRC but it was pushed down in priority by another submission at a higher fee level, and there is past the pay limit and will not be paid by the staker. The STALE_CANCEL is the end stage of PENDING_CANCEL, where an unpaid MRC remains in the memory pool, but refers to a block that is no longer at the head of the chain. The tooltip for all of these error conditions has helpful commentary for the user.

Note that the "ELIGIBLE" state is the only state where the submit button is enabled.

For the ModelStatus, this controls whether the MRC status and submission widgets are displayed or hidden behind a blank screen with an information message that MRC submissions are not available. The MRC status and submission widgets are only shown when the ModelStatus is VALID. All other states result in a cover screen and an appropriate information message.

Here is a screenshot of the normal state with the wallet unlocked, where the minimum time since the last payment has been met, and the queue is empty:

After submission on a full queue where the node took priority and displaced someone else due to a higher fee:

Notice that the submit button is disabled because there is a pending MRC. There is a green check box to indicate the MRC submission was successful.

This closes gridcoin-community/Gridcoin-Tasks#218.

[jamescowens]

@div72 I applied the one suggestion on the string handling. Anything else of note on this?

[div72]

@jamescowens The signaling from numBlocksChanged on mrcmodel.cpp#L63 seems a bit unnecessary, and I have a couple of nits but nothing major.

I am waiting for my testnet beacon to get verified, but I can give a code review ACK if @denravonska can give a tested ACK.

[denravonska]

Test ACK on testnet:

• Claim not possible when out of sync
• Claim not possible without a beacon
• Claim not possible if one is pending
• Claim not possible if too soon from a previous one
• Claim possible if eligible
• Claim is paid out as expected
• UI updates when conditions are updated (IIRC)

Not tested priority behavior as that had been tested by @jamescowens already.

[div72]

utACK.