fix: fix dacite deserialization compatibilty, deprecatation warnings, import error and update mypy, black and poetry

[mdevolde]

Issue

Fixes#812

Description

This change updates the dacite configuration in serialize.py so that datetime values are handled only through the existing type_hook (parser.parse) and are no longer also included in cast.
This avoids a double-conversion path introduced by newer dacite versions, where a JSON datetime string is first parsed into a datetime.datetime object and then incorrectly cast again, causing manifest deserialization to fail.
With this change, serialization behavior remains compatible with the existing code path while restoring support for newer dacite releases such as 1.9.2.

I also replaced deprecated pydantic_encoder usage with pydantic_core.to_jsonable_python in serialize.py (and so, I bumped pydantic version).

Testing

Run the relevant test suites with:

poetry run pytest tests/unit/electionguard

These tests include tests/unit/electionguard/test_manifest.py, the tests that we just patched with this PR.

I ran the test with python 3.9, 3.11, 3.13.

[mdevolde]

Seems that this old version of mypy doesn't support pydantic v2. I'm looking at this.

[mdevolde]

Okay so, I updated mypy to the most recent version that support python 3.9, and I took the opportunity to update black to the most recent version that support python 3.9.
As I updated the version of mypy and black, I had to apply the new advices given by poetry run black --check . and poetry run mypy src/electionguard src/electionguard_tools src/electionguard_cli src/electionguard_gui stubs.
It seems that there is a lot of changes but, in reality, except for the changes described above in serialize.py, they are just formatting and typing changes, that has no impact on the functional code.
Obviously, I ran the testing pipeline to ensure that all is good.

[mdevolde]

At this stage, one option might be to bump the poetry version too, to ensure we have a fully modern and functional development environment (because the current version doesn't support very well lastest versions of python).
If you’d like, I can look into that as well as part of this PR.

[mdevolde]

I made the commit to demonstrate the upgrade of poetry (and so, pyproject.toml) to current standards, if you don’t want it, I can revert the commit

[mdevolde]

I missed a fixed version of poetry in the Makefile, it's fixed!

[mdevolde]

Just patched the old config param poetry config installer.modern-installation false that is not relevant anymore.

[mdevolde]

By running the CI on my Linux, I noticed an import error in the GUI, and some deprecation warnings about datetime.utcnow(). Fixed!
Again in a separeted commit so it is easier for you.
If you are ok, I can merge the commits in just one.

[mdevolde]

The code seems good, Linux/Mac checks are ok.
I'll check at the linter advices to have a fully cleaned code.

[mdevolde]

So, I corrected the pylint warnings, and I allowed Eel and setuptools to be bumped.
Same as above, I made splited commits to have a easier review to you, but I can merge them after.
Normally, all tests should pass now.

[mdevolde]

The two disabled categories that I added in pyproject.toml in pylint section (so, broad-exception-raised, too-many-positional-arguments) are justified because without ignoring them, I should edit funcs params or raised exceptions.

[mdevolde]

It's mypy's turn to complain x)
I'll fix that a little later.

[mdevolde]

Mypy warnings from dependencies are patched, and mkdocs version is bumped to ensure that the documentation build properly.

[mdevolde]

@jungshadow Hi! Sorry to tag you. If you need any help understanding a change, don't hesitate to ask. Of course, there is no hurry!

[jungshadow]

@mdevolde This all looks good and I appreciate the quality of life improvements. Oddly, I got an error on first build, but I think that's largely because I tried to be too clever by half (NB: it's a running gripe I have with this project that the Makefile is too opinionated for those of us with existing pyenv, poetry, et al. environments). I'd like to migrate the entire package management to uv at some point, but that's a story for another day. All that (and too much) said, LGTM!

[mdevolde]

@jungshadow thanks again for the review ! I'm used to uv, so it's not a problem for me to migrate the development environment to uv if you want!

[jungshadow]

@mdevolde Let's scope it out and add it to the issue pile.

[mdevolde]

@jungshadow sure ! I will open an issue about, and when I'll have some free time, I'll open a PR about.

[jungshadow]

Thanks, @mdevolde!