Record type of care null states

[JunTaoLuo]

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

⚠️ TeamSites ⚠️

Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the #sitewide-public-websites Slack channel for questions.

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

• This PR adds appointment details null state recording. While specifically this only adds the null state tracking for type of care and any null state for review and evaluation, the same function and approach will be used for the other fields as well.
• I included two tickets in this PR to demonstrate the approach. The other fields will be added in followup PR(s) once we agree on the approach.
• Appointments (VAOS) Team
• This is not behind a Flipper

Related issue(s)

• Add appointment details null state tracking - Type of Care va.gov-team#98976
• Add appointment details null state tracking - any null state va.gov-team#99006

Testing done

• I tested locally using console.log and a dummy field type. See 6477739 for details on the code I used for testing.
• I tested the following scenarios
  • Missing type of care
  • Not missing type of care
  • Provider not applicable
  • Expected total and missing any for the above scenarios
• I updated our layout unit tests to account for the new messages

Screenshots

N/A

What areas of the site does it impact?

Appointments (VAOS)

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

[JunTaoLuo]

I'm not actually certain that this is the best spot to put this utility but I did see several other record events utils here. Any suggestions?