feat(update RAI withdraw behavior): Update RAI withdraw behavior to accommodate Medicaid specific biz logic

[mdial89f]

Purpose

This changeset updates the RAI Withdraw mechanics to accommodate the specifics of Medicaid RAI response withdrawal.

Linked Issues to Close

Closes https://qmacbis.atlassian.net/browse/OY2-26753

Approach

The RAI lifecycle for medicaid is different than chip.
For medicaid:

• There can only be exactly one RAI object for a submission.
• The state needs to be allowed to withdraw and re-respond to that same RAI multiple times.
  For chip:
• There can be one to many RAI objects for a submission.
• The state will not re-respond to an RAI. If a response is withdrawn and a new response is required, CMS will issue another RAI.

The updates to the api's withdraw rai function reflect this.

• For medicaid, on withdraw, we nullify the received date, thereby re-opening the RAI and sending the record back to Pending - RAI status. We also set the withdrawn date.
• For chip, on withdraw, we leave the received date as is, set the withdrawn date, and send the record back to Pending.
• For all authorities, we set a detailed message in the status memo field that includes the received and withdrawn dates of the withdrawn package. We do this since Medicaid is overwriting data on the RAI object, and we don't want data loss. Although our mako system will log all events to status memo as they happen, including the response received event, we can't guarantee that the status memo already has that information since we cannot guarantee that the response was submitted through mako. So, our status memo note is verbose. And while it's detailed info is only required for medicaid (since only medicaid overwrites data), I went ahead and set the same message format for all withdraw package events.

MEDICAID Example, after rai response withdraw

CHIP Example, after rai response withdraw

Assorted Notes/Considerations/Learning

During the course of work, it was found that the issue rai action was not appearing when expected. For a chip submission, after an rai response is withdrawn, a new RAI may be issued. However, it wasn't showing up. I fixed what I believe to be a fault in the rule logic. The logic now allows RAI issuance if there are no RAIs or the latest RAI is complete.
I updated the checks to reflect the logic of:

• a respondable RAI is one with a requested date and no received date.
• an RAI is issuable if there are no RAIs, or the latest RAI has a received date.
• and RAI response is withdrawable if it has a received date and no withdrawn date.

[mdial89f]

There is obviously a lot of refactor opportunity here...
I went with the verbose approach, and didn't bother condensing anything, as the api actions in general are soon to be refactored.

[pkim-gswell]

[github-actions]

🎉 This PR is included in version 1.7.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.5.0-val.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀