Fix python client's user-agent version

[melange396]

Change the way the python client determines its own version number.

The current implementation uses importlib to get the "installed version" of the package and set it in the user-agent string. This is apparently fragile enough that is misreporting its version number to the API server (in a number of places on our own systems, no less!). Maybe it worked better in the past before it was updated to stop using pkg_resources. ¯\_(ツ)_/¯

On a single one of our automation servers, different jobs make requests that announce user-agents of both delphi_epidata/0.0.11 (Python) and delphi_epidata/0.0.12 (Python) (among others!). To make it even more ridiculous, the addition of the " (Python)" suffix didn't come around until version 4.1.0. This does suggest the possibility of a misconfiguration of some sort on the machine, but the way the client is implemented makes that even more difficult to track down.

Unless someone has a better idea, we can keep something like the existing try structure and attempt to get the version from the package but fall back to the "0.script" text if it doesnt work, or we could just be lazy and add delphi_epidata.py to the bumpversion config.

[dshemetov]

So of course, I end up finding the perfect guide for this (by the Python Packaging Authority) only after we fix it, but it's all good because this guide provides many approaches and we ended up doing approach (2) they recommend here single-sourcing the package version. And interestingly, approach (5) is the one we did previously and it has this caveat:

Be aware that the importlib.metadata API only knows about what’s in the installation metadata, which is not necessarily the code that’s currently imported.

So maybe that's the edge case we ran into 🤷