Changes to make adding and removing sample cameras more flexible

[vshekar]

An initial commit that refactors the zoom radio buttons into a zoom slider with multiple levels that correspond to zoom levels is in #312

The zoom slider should be designed to be flexible enough to accommodate any number of zoom levels/cameras/FOVs.

Currently there are 2 pieces of information that are needed to define the properties of the zoom camera.

1. URL of feed. Example: https://github.com/NSLS-II/lsdc/blob/4d069dd21bbbc59b3812fe973cd9b8c65c21c9d5/daq_utils.py#L61
2. Height and width of camera FOV. Example: https://github.com/NSLS-II/lsdc/blob/4d069dd21bbbc59b3812fe973cd9b8c65c21c9d5/daq_utils.py#L65

There is also a separate BL parameter to keep track of the number of cameras called sampleCameraCount. Here: https://github.com/NSLS-II/lsdc/blob/4d069dd21bbbc59b3812fe973cd9b8c65c21c9d5/daq_utils.py#L76C3-L82

Issues with current setup:

1. Configs are hard coded to certain variable names such as lowMagCamURL, highMagCamURL, highMagZoomCamURL,
   and lowMagZoomCamURL
2. FOV widths and heights are ambiguously named and FOVs of zoomed views are calculated based on non zoomed values. For example: highMagFOVx and highMagFOVy is the width and height of the highMag camera. Throughout the code x and y are used interchangeably to represent width and height as well as co-ordinate points making code difficult to read and reason. Secondly, highMagFOVx is the FOV width for Zoom 3 and FOV width for Zoom 4 is calculated in code as highMagFOVx / 2. This means that any changes to Zoom 4 or addition of other zoom levels requires changes to code rather than configuration.

Note that these config params are either simple string or int values in the mongo db. I propose the sample camera config be changed to the following format:

"sampleCameraConfig": [
         {
            "url": "http://nsls2.bnl.local:9999/C2.MJPG.mjpg",
            "fov": {"width": 638, "height": 401}
        },
        {
            "url": "http://nsls2.bnl.local:9999/C1.MJPG.mjpg",
            "fov": {"width": 300, "height": 201}
        },
    ]

Advantages to such a format are:

1. Single BL config parameter for all zoom levels
2. Counting the elements in the list will tell you how many zoom levels there are
3. Zoom level information organized logically
4. Most importantly zoom camera levels are set using configuration parameters rather than code. UI will change based on params

[JunAishima]

sounds like a lot of the issues I had when looking at this a couple of weeks ago. if you're going to need to define a different zoom level stream, why constrain zooms 2 and 4 to be exactly double the magnification of 1 and 3, respectively?

I think it also looked like a lot of repetitive code as well, as I think you saw in #312