Move insertion device lut to daq-config-server

[oliwenmandiamond]

No description provided.

[Relm-Arrowny]

Currently, the daq-config-server only accepts a file path, making it impossible to distinguish between these two configurations since they share the same filename.

We probably have two potential solutions for this:

• Add an additional parameter: Modify the server to accept a secondary argument alongside the file path. This would resolve the naming conflict and allow us to handle beamline-specific logic via parameter settings rather than separate models.

• Use unique configuration files: Maintain separate, uniquely named files for different LUT settings. This is alternative that avoids the need for server modifications and removes the dependency on custom models.

This probably effect the restructure #165 .

[Relm-Arrowny]

There is a 3rd option we can also split the data file into two but it will spin ever more models

[oliwenmandiamond]

Splitting your ID config files is the simplest solution. This means we can also remove the Source Field for LookupTableColumnConfig. I mentioned this awhile back as only I10 uses this column where it is simpler to split like i09

[Relm-Arrowny]

Option 3 only resolves the filename conflict, we would still need to instantiate multiple models in the code for every ID configuration.

Option 2 is an improvement because it encapsulates all parameters within a beamline_lut_config file, allowing for easy modification without requiring a new model for each beamline.

However, I think the additional parameter is the best way forward. It would allow us to eliminate the FILE_TO_CONVERTER_MAP entirely, Relying on only a few unified models. This would also prevent the need to maintain an ever-growing list of individual configuration files/models.

[oliwenmandiamond]

This I do agree slightly agree with as additional parameters would give us the flexibility and eliminate the growing converter functions. However, then I don't think it's worth the effort.

So at the moment, we do this

class ConfigServerEnergyMotorLookup:
         ...
         file_contents = self.config_client.get_file_contents(
            self.path, reset_cached_result=True
        )
        return convert_csv_to_lookup(file_contents, lut_config=self.lut_config)

Currently, we can do this:

my_model = self.config_client.get_file_contents(self.path, desired_return_type=MyModel)

And you want to do able to do this

my_model = self.config_client.get_file_contents(self.path, desired_return_type=MyModel, **kwargs)

At this point, is it really worth the effort for it take custom parameters when we can do this on our side anyway?
We should just update our model to do this instead

class ConfigServerEnergyMotorLookup:
         ...
         file_contents = self.config_client.get_file_contents(
            self.path, reset_cached_result=True
        )
        return MyModel.from_content(file_contents, lut_config=self.lut_config)

The simplest solution is if the model can take a single argument of file contents, then it can support the desired_return_type feature. If it can't, then the model should live in daq-config-server but when loaded, the file contents should be returned as string and additional args should be given client side. However, the loader function lives on the model.

I guess that does make it slightly confusing though, so maybe supporting additional kwargs your model needs for loading is a much better way as then it is driven by configuration you provide to the client function rather than endlessly creating static functions for loading a simple model.