Move modify_desired_date logic into appointments service

[JunTaoLuo]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Summary

• As part of the vets-api consolidation work, we want to move the date modification logic from the appointments controller to the appointments service.
• This area is owned and maintained by the Appointments team.

Related issue(s)

• ZenHub Ticket

Testing done

• New code is covered by unit tests
• The existing unit tests were moved from the controller to the service

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

[JunTaoLuo]

@cferris32 The only difference between this PR and what we worked on during our pair session is that I moved this date modification block from the top of the method to after the post requests.

I noticed while fixing tests tests that in cases where patientIcn is missing, we would make a redundant get facilities request if we had this logic at the beginning of this method. Instead, if we had this logic here, the post requests above will raise exceptions first and we won't make the get facilities request which I think is slightly better. Let me know if you disagree and I can move the logic back to the top of the method and update the VCR cassettes instead.

[cferris32]

I think it should be good this way, that's a nice catch and saving on a redundant call is preferred. I don't think there should be anything else this impacts

[cferris32]

LGTM