DAC changing custodian token would lead to a missed period of payment for custodians

[dallasjohnson]

The current design flow for custodian payments is as follows: (using period 1, 2, 3 to help explain the timeline between newperiod calls.

1. Candidate-A sets their requestedpay during period 1 which is saved in the candidates table for the next upcoming election (newperiod). The allowed amount and token for requestedpay is based on the setting in the custodian config for requested_pay_max.
2. A newperiod is called. If Candidate-A is a current active custodian they would be paid based on their requestedpay amount, checked with the current config setting for requested_pay_max.
3. Assuming Candidate-A was re-elected for period 2 it would copy the requested pay from the candidates table into custodian table for them to be paid for that amount on the next newperiod at the end of period 2.

The problem:
If the requested_pay_max token type was changed between periods 1 and 2 then when the newperiod is called at the end of period 2. It would skip the candidates with requestedpay token that mis-match the config requested_pay_max token type (for the first period since the change this would be all of them as setting requestedpay would be checked against the requested_pay_max). In addition if a candidate does not update their requestedpay during period 2 they would also miss payment for period 3 etc.

Background:
The reason for this initial design was to prevent candidates from updating their requestedpay in the last moment before newperiod was called but after voters had voted for them.

** Potential Solution:**
If the period pay token was set for the upcoming period as a separate setting from the requested_pay_max then that could be used for the distributing pay action and allow for requested_pay_max to be changed separately for the following period. This would require a schema change to the custodian config to add another field.

[michaeljyeates]

Maybe we could just impose special restrictions on changing the requested pay token, you can change it but you must either run a convert action on the existing data or delete it before continuing.

[michaeljyeates]

We could even use the ratio of the previous max pay to the new max pay to automatically convert any existing data. eg if the previous pay was 5 EOS and the new one is 100 DAC then we can assume the conversion rate of 20:1 for all the requested pay.