Interim non-handling of date variables for bubble markers (but allows EdaDataService#309 to be merged)

[bobular]

Compiles - not tested yet because the only back end with dates and map data is down at the mo.

Should provide the following (check off when tested)

• date variables disabled from bubble marker variable picker
• no malformed service payload errors
• normal functioning of bubble markers for non-date variables

If there are any developers' saved user analyses with date variables, these may or may not work, but this is not an issue for actual beta users.

Testing would require a local back end from VEuPathDB/EdaDataService#309 running. I'm not expecting this for the PR review.

If/when approved, we should coordinate the back end merging with @dmgaldi

[bobular]

Note to self:
For testing with local(ish) back end (with dfalke-b.vectorbase wdk service), this will get me direct to the ticks and save a bit of time
https://localhost:3000/maps/DS_e18287e335/VVbYZ4P

[bobular]

Merged latest from main. Tested against local VEuPathDB/EdaDataService#309 back end. All working fine.

Note that this does NOT introduce date variable handling for bubble markers. This will come after the collections-related refactor.

[dmfalke]

I'm trying to test this branch, using a local backend, but responses are taking way to long, and I'm getting errors I've never seen (Expected 6 columns but parsed 1 in line:2003-Desplaines-Valley-Mosquito-Abatemen).

The code compiles, so I will assume things will work better in a more capable environment.

[bobular]

I'm trying to test this branch, using a local backend, but responses are taking way to long, and I'm getting errors I've never seen (Expected 6 columns but parsed 1 in line:2003-Desplaines-Valley-Mosquito-Abatemen).

The code compiles, so I will assume things will work better in a more capable environment.

Was that a back end error?