canceling the vesting issuance won't decrease allVestAt which would cause self DOS as users interact with system or attacker can cause DOS intentionally 
Audit: 2023-01-reserve-findings
Severity: MEDIUM

# Lines of code

https://github.com/reserve-protocol/protocol/blob/df7ecadc2bae74244ace5e8b39e94bc992903158/contracts/p1/RToken.sol#L406-L418
https://github.com/reserve-protocol/protocol/blob/df7ecadc2bae74244ace5e8b39e94bc992903158/contracts/p1/RToken.sol#L655-L714
https://github.com/reserve-protocol/protocol/blob/df7ecadc2bae74244ace5e8b39e94bc992903158/contracts/p1/RToken.sol#L342-L370


# Vulnerability details

## Impact
When users issue new RTokens, code creates vesting deposits and calculates finish time and increase the amount of the `allVestAt` but if users cancel their issuance in vesting time code don't decrease the value of the `allVestAt`. this would cause natural DOS by design as users interact with protocol and issue and cancel. also attacker can get a small loan and repeat 1000 times of issue() and cancel() for those tokens and increase `allVestAt` as much high that no one be able to create RToken. the default is issuance rate is 6% in each hour and each month has 720 hour so if attacker get a flash loan for basket tokens worth of 6% RToken backed tokens and 720 times repeats `issue()` and `cancel()` then `allVestAt` would increase 1 month and no one be able to create RToken in that Month and attacker needs to do this each month one time to completely block protocol. this is a critical issue because it is happing normally by design as users interact with system and also attacker can intentionally block the new RToken supply and break the protocol and cause losses for RSR stakers.
There is a griefing attack too as other users call `issue()` and see that they have to wait long time for minting new RTokens they need to call `cancel()` and pay two transaction gas. there is no parameter that user can specify maximum time they allow for vesting time when they call `issue()` and code can create vesting issue with any delay for user and user has no control over the maximum allowed time and user can't calculate the time before transaction too because other transactions can change the state of the contract before user transaction mining.

## Proof of Concept
This is `cancel()` and `refundSpan()` code:
```
    function cancel(uint256 endId, bool earliest) external notFrozen {
        address account = _msgSender();
        IssueQueue storage queue = issueQueues[account];

        require(queue.left <= endId && endId <= queue.right, "out of range");

        // == Interactions ==
        if (earliest) {
            refundSpan(account, queue.left, endId);
        } else {
            refundSpan(account, endId, queue.right);
        }
    }

    function refundSpan(
        address account,
        uint256 left,
        uint256 right
    ) private {
        if (left >= right) return; // refund an empty span

        IssueQueue storage queue = issueQueues[account];

        // compute total deposits to refund
        uint256 tokensLen = queue.tokens.length;
        uint256[] memory amt = new uint256[](tokensLen);
        uint256 amtRToken; // {qR