Handle Breakers::OutageException in Post911GIBillStatusesController

[AdamKing0126]

The service which Lighthouse uses to request GI Bill status information for a veteran occasionally experiences outages. Vets API uses the Breakers gem to better handle outages by raising the OutageException class. The ApplicationController is configured to raise a ServiceOutage error in these cases.

This commit adds handling for Breakers::OutageException in the Post911GIBillStatusesController's show method, and to the associated service class which makes a request of Lighthouse. When a Breakers::OutageException is encountered, it is simply raised, allowing the ApplicationController to handle it.

The ServiceOutage class was modified to include a status code of 503 in the data passed to SerializableError. This status code represents "Service Unavailable", which is the appropriate code to use when a service outage occurs.

Tests have been updated to cover this new exception handling logic and ensure that the correct HTTP status code and error message are returned when a Breakers::OutageException is raised.

Related issue(s)

https://github.com/department-of-veterans-affairs/va-iir/issues/828

Testing done

• [x] New code is covered by unit tests
• Previously a 500 error would be raised, because a Breakers::OutageException does not have an errors attribute
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing

What areas of the site does it impact?

• Modify ServiceOutage object: include status: 503 in the error
• Modifications to Post911GiBillStatusesController and BenefitsEducation::Service to allow Breakers::OutageException to bubble up and be handled by ApplicationController (included in ExceptionHandling)

Acceptance criteria

• [x] I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• [x] No error nor warning in the console.
• [x] Events are being sent to the appropriate logging solution
• [x] Documentation has been updated (link to documentation)
• [x] 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 (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