VACMS-13613 cap data push (newer)

[swirtSJW]

Description

Relates to #13613

This PR was created as a result of #16771 and is the replacement for #13777

Blocked

This is currently blocked by Lighthouse not having an endpoint that we can push this data to. We currently have no place to push this data to. Once Lighthouse builds and endpoint to receive this data, which hopefully will be the same endpoint we need to push VBA data, then we can proceed with test pushes to make sure they receive it.

Testing done

Since this is waiting on an endpoint to push to, testing has not been done yet.

Screenshots

QA steps

What needs to be checked to prove this works?
What needs to be checked to prove it didn't break any related things?
What variations of circumstances (users, actions, values) need to be checked?

As user admin

1. Edit a Vet Center CAP that is not published. Make a change and save it without publishing.

   • Visit the Post API queue and Validate that nothing was queued. CAPS should never be pushed until they are published.

2. Edit the same node and publish it.

   • Visit the post API queue and Validate that the CAP was queued
   • Validate that the queued data is complete (address, phone(s), lat lon, title, status, status more_info ...)

3. Edit a different published cap, make and save a change as draft

   • Visit the Post API queue and Validate that nothing was queued.

4. Grab screenshots of the queued items

5. Coordinate with Lighthouse to let them know you are attempting a push.

6. Process the queued items

   • Validate that the items were removed from the queue.
   • Validate that sandbox-Lighthouse received the items.
   • Validate that the data recieved matched the screencapped queue item(s).

7. Archive a the cap you just sent to Lighthouse.

   • Validate that it was queued as deleted... whatever data bit that LH says we need to send to indicate the facility is gone.

8. Process the queue.

   • Validate with LH that they received the deletion
   • Validate with LH that they set whatever status they needed to that would indicate the facility is closed/gone.

Definition of Done

• Documentation has been updated, if applicable.
• Tests have been added if necessary.
• Automated tests have passed.
• Code Quality Tests have passed.
• Acceptance Criteria in related issue are met.
• Manual Code Review Approved.

Select Team for PR review

• CMS Team
• Public websites
• Facilities
• User support
• Accelerated Publishing

Is this PR blocked by another PR?

• DO NOT MERGE

Does this PR need review from a Product Owner

• Needs PO review

CMS user-facing announcement

Is an announcement needed to let editors know of this change?

• Yes, and it's written in issue ____ and queued for publication.
  • Merge and ping the UX writer so they are ready to publish after deployment
• Yes, but it hasn't yet been written
  • Don't merge yet -- ping the UX writer to write and queue content
• No announcement is needed for this code change.
  • Merge & carry on unburdened by announcements

[swirtSJW]

As of today, these are the things that are unfinished on this.

• LH providing us a new non-VAST endpoint we can push to. Ideally this should be the same endpoint for creation as for updates and deletions.
• LH providing the flag or field we have to set to so that they recognise a facility deletion.
• Full testing of this with LH.
• Adding coverage to the existing tests
  • /tests/phpunit/API/PostApiQueueTest.php
  • /tests/phpunit/Content/FacilityStatusQueueTest.php