Only include digits in 2122a representative phone number

[opticbob]

Summary

• This work is behind a feature toggle (flipper): YES
• (Summarize the changes that have been made to the platform): The PDF filling of the representatives phone number on the 21-22a now only allows digits to be filled in. The form already has dashes so we only need the numbers.
• (If bug, how to reproduce)
• (What is the solution, why is this the solution?)
• (Which team do you work for, does your team own the maintenance of this component?)
• (If introducing a flipper, what is the success criteria being targeted?)

Related issue(s)

• 21-22a: Exclude dashes when adding the rep phone number to the PDF va.gov-team#96853
• Link to previous change of the code/bug (if applicable)
• Link to epic if not included in ticket

Testing done

• New code is covered by unit tests

• Describe what the old behavior was prior to the change: The data comes from the database and has no formatting requirements meaning some phone numbers were in the 987-654-3210 format. The end result with the dashes on the form was like this:
  

• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing: Prepare a request object with the staging frontend and submit it to the backend. Choose a rep with dashes or parentheses in their phone number. The end result will be a properly formatted phone number on the PDF.

• If this work is behind a flipper:

  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas): This only impacts the 21-22a PDF generation in the representation_management module.

Acceptance criteria

• I updated 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?

[github-actions]

Backend-review-group approval confirmed.