chore: optimise planning constraints requests

[jessicamcinchak]

Joann at Gloucester is still reporting partial GIS queries: https://opendigitalplanning.slack.com/archives/C05NQJK5S9L/p1726495149134779

Double-checking a few of our configs here to see if there's anything we've missed:

• Can we filter Planning Data metadata response fields similar to entity?
  • /dataset endpoint does not currently support include/exclude field params so nothing we can do here https://www.planning.data.gov.uk/docs
• Can we optimise /roads OGC query?
  • Confirmed this is working as expected, there's not much way around a slow string-matching USRN query! Shared details with Steve at Planning Data about if/how roads might be a candidate for adding to the Planning Data platform in the future which could simplify a bit (eg consistent performance/caching/uptime, but still need to handle non-geospatial query method!)
• Is loading logic correct throughout? Are we properly handling scenarios where one of two requests errors (ui feedback & passport vars)?
  • Again, properly looked this over & we're doing exactly what we want! If one of the two requests fails, you only see results from the other and any "failed" variables are not added to passport at all, therefore prompting users to manually see questions

Only changes:

• Split up components in Public.tsx & renamed PlanningConstraintsContent → Presentational as this is a more established pattern elsewhere among frontend components

[github-actions]

Removed vultr server and associated DNS entries

[RODO94]

@jessicamcinchak trying to track and follow the code here. Are most changes on moving the jsx content to Presentational.tsx file from the Public.tsx file?

I see big diff around the handleSubmit() but it looks mostly like it has only changed position in the code rather than any logical changes?

Should I be testing any logic?

[jessicamcinchak]

@RODO94 sorry for confusion - this ended up being a pure quick refactor for readability/smaller component files, no logic changes

[RODO94]

@jessicamcinchak thanks for clarifying, looks good to me. Thanks for picking up all the comms on this with Planning Data