Zino sometimes logs a scary looking `PanicException`

[lunkwill42]

Sometimes, users will find that Zino logs this scary looking exception:

Traceback (most recent call last):
  File "/home/zino/.zino/lib/python3.11/site-packages/apscheduler/executors/base.py", line 131, in run_job
    retval = job.func(*job.args, **job.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/zino/.zino/lib/python3.11/site-packages/zino/utils.py", line 33, in wrapper
    result = func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/home/zino/.zino/lib/python3.11/site-packages/zino/state.py", line 48, in dump_state_to_file
    statefile.write(self.model_dump_json(exclude_none=True, indent=2))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/zino/.zino/lib/python3.11/site-packages/pydantic/main.py", line 519, in model_dump_json
    return self.__pydantic_serializer__.to_json(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pyo3_runtime.PanicException: dictionary changed size during iteration

This is most likely because serialization and dumping of the running state to disk takes place in a separate thread in order not to block the router polling - however, since there are no locking mechanisms in place, the main thread may be modifying the data structures as Pydantic is trying to serialize them to JSON data.

This problem is somewhat mitigated by #364, which ensures the state file is not corrupted if this error occurs. Committing the state to disk will, however, be delayed by this error until the next time a dump is scheduled.

This problem was mentioned in #364 and #365 tries to solve it. This issue is here to document what the error looks like, so users who experience it can find this issue.