API-45277 - Updates to VnpProcServiceV2 for POA request creation

[mchristiansonVA]

Summary

• This work is behind a feature toggle (flipper): NO
• Updates to the XML structure and contents to effect a successful vnpProcRequest call to BGS, with attendant updates to the coroporate database as expected.
• Note that this includes an update to the POA request orchestrator to comment-out the call to TerminateExistingRequests that normally occurs prior to the remainder of the create request flow. This was done at Kayla's suggestion to temporarily work around issues we are having with the call to read_all_veteran_representatives in the terminate flow.

Related issue(s)

• API-45277

Testing done

• New code is covered by unit tests
• During testing and debugging with Harlow, we found that our existing calls to BGS' VnpProcServiceV2 were no longer successfully inserting all required fields in the corporate database.
• Worked with Harlow to confirm that the included implementation of our service and related XML results in a successful BGS call and corp database update.

What areas of the site does it impact?

modules/claims_api/app/services/claims_api/power_of_attorney_request_service/orchestrator.rb
modules/claims_api/lib/bgs_service/vnp_proc_service_v2.rb

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 (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

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[rockwellwindsor-va]

@mchristiansonVA Why do we need to disable this here? Is it because of the '21-22 ' thing? Just want to make sure I understand why we need this change too.

[mchristiansonVA]

I added a comment in the summary—this was done because we were having issues with the read_all_veteran_representatives call breaking the flow before we got to the create steps, and we decided in standup to just take this approach at the time. But looking again I think you addressed the issue with the handling an empty list of obsolete requests. I'll update to remove the disabling.