Add fileExtension to configuration query

[tpoliaw]

Fixes #52

[tpoliaw]

More naming-is-difficult decisions. I'm not sure whether it should be fallbackExtension, fileExtension, extension, something else? 'fallback' doesn't really make sense when it's not really a fallback anymore. (file)extension sounds like it could be the extension used for scan files etc.

Thoughts @callumforrester, @DiamondJoseph ?

[callumforrester]

My concern here is that we may be dealing with systems that decide their own file extensions rather than letting us decide for them. For example a detector that can only write TIFFs, or that we're just coupling ourselves to nexus when a beamline might want multiple archive formats (I think B23 is like this?), but I may be misunderstanding.

[tpoliaw]

but I may be misunderstanding

That's what I was worried about but I'm not sure what would make it less ambiguous. The file extension is nothing to do with data files being written. It is the extension of the number file GDA creates in its var directory, eg 12345.i22

[tpoliaw]

It's just called extension when setting it via the configuration mutation. Whatever this ends up being, they should probably be made to match.

[callumforrester]

If it's always going to be a number then we could copy ophyd-async and AreaDetector and call it fileNumber: https://github.com/bluesky/ophyd-async/blob/efe14d8561914c358c5ed5c1c36e195223699402/src/ophyd_async/epics/adcore/_core_io.py#L138

[tpoliaw]

It's not going to be a number. In most cases it would be the beamline name, but occasionally it's something like scanbase_numtracker or tmp. I think we've settled on tracker_file_extension in #57.

[callumforrester]

Happy with that then, although I'm not sure I have a sufficient understanding of how GDA var works to review this properly