LG-10785: Move full address entry PO search into the @18f/identity-address-search package

[sheldon-b]

🎫 Ticket

LG-10785

🛠 Summary of changes

• Move the full address entry components from the document-capture javascript package into the address-search package
• Move the URLs for the address and location search endpoints into the InPerson context provider. This removes a dependency from full address search on single entry address search and allows tests to inject this dependency instead of importing it from the component
• Pass usStatesTerritories down into the full address entry components instead of having the low level components depend on the InPerson context provider

🗺️ Next Steps

Once this PR is merged I'll publish a new version of the @18f/address-search package

[sheldon-b]

The pattern for other URLs is for the backend to pass them to the javascript app. I didn't do that here because it's a larger refactor, but I'm leaning towards creating a ticket for it

[sheldon-b]

eg here and here

[sheldon-b]

There aren't good default values for these. I could move the logic for constructing the URLs to here, or follow the pattern for inPersonURL (which is for it to be optional and no default is defined). Or just leave it as-is here

[gina-yamada]

I am not sure the best answer here. I'd like to hear opinions on this.

[gina-yamada]

I like that you shortened file name. Now component name is the same as the file name.

[gina-yamada]

I understand why you decided to pass in usStatesTerritories as a prop. If we use this component in sites, I imagine we will need to write an issue to get usStateTerritories in sites (help center). (I did not look into how we are getting these- jumping into another meeting). I imagine the lift to do this in sites and pass it in is not large so am okay with passing it in- just calling it out as some additional work I think

[sheldon-b]

That's a good point. For reference how this works in identity-idp is:

1. US states and territories are defined in the Ruby app
2. They're passed into the javascript application on the document capture page
3. They're loaded into the InPerson context, per this PR
4. They're passed down into the components in the PO search step, per this PR

As-is we'll have to redefine them in the identity-site repo

An alternative is that we could write a script to read from the Ruby file and write to a javascript file, and then publish the generated javascript file as part of an npm package. And then in the Ruby file add a file comment saying something like,

If you change this set of states/territories be sure to go run script bin/update-states-and-territories.sh and publish a new version of the npm package

I'm going to go ahead and merge this PR. If we do refactor it in some way I think it should be part of a different ticket. But let me know your thoughts about it

[gina-yamada]

I think a new ticket is a good idea, extra work and out of scope to get this working in identity-sites. I think both are fine. I don't think the list will change much over time just as long as we can think of a way to try to ensure both get updated in the future

[gina-yamada]

I did test your branch. I tested with mock facilities, with no mock facilities, and hit PO (usps dev) and was successful. For all tests, in_person_full_address_entry_enabled in my application.yml file was set to true.

[gina-yamada]

I am not seeing any concerns here. Manual testing all checks out and code change all make sense. I did have one comment about usStateTerritories- not a blocker just a thought/something to consider.