Use config server for undulator config

[jacob720]

Fixes DiamondLightSource/mx-bluesky#1494

Required by DiamondLightSource/mx-bluesky#1497

Instructions to reviewer on how to test:

1. Confirm config is read through the config server

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.11%. Comparing base (a039d73) to head (c3f2952).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1768   +/-   ##
=======================================
  Coverage   99.11%   99.11%           
=======================================
  Files         319      318    -1     
  Lines       12267    12327   +60     
=======================================
+ Hits        12158    12218   +60     
  Misses        109      109           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Villtord]

I am not sure if this hardcoded config server is a good solution long term. I understand that it works fine now, but what if for some reason you need to divert your config server to a different endpoint - you would have to change the path here.
It feels like we need some king of an interface or a lookuptable provider which should probably be configured separately.

[DominicOram]

Snap! I think my comment at #1773 (comment) is basically the same thing. I think we should define it in the ixx.py files like we do for e.g. a path provider

[Villtord]

yep, agreed - in an even broader perspective I don't think we should need daq-config-server as a dependency - but that's for later development DiamondLightSource/daq-config-server#157

[rtuck99]

Why not just keep the lookup table contents as a field in the device, and then you don't need to keep a reference to the config client, or re-read the config when you access it (which is going to be the same anyway until we rebuild the device)

[rtuck99]

Plus, I think this gives potentially nicer failure behaviour in that the failure to reach the config server happens when you construct the device (which happens on baton handover or plan invocation) instead of later on which may potentially be some time afterwards.

[rtuck99]

Same consideration here really

[rtuck99]

Approved, just need changes as discussed