Replace `none_type = type(None)` indirection usage for better static analyzer support

[rob3c]

Actions before raising this issue

• I searched the existing issues and did not find anything similar.
• I read/searched the docs

Is your feature request related to a problem? Please describe.

The current use of none_type = type(None) for type annotations in the OpenAPI generated code causes significant issues for static analyzers like Pylance/Pyright and Mypy. While technically valid under PEP 484, it introduces indirection that breaks type narrowing.

Describe the solution you'd like

Replace, for example:

# mode_utils.py
`none_type = type(None)`

# data_meta_read.py
class IDataMetaRead(IModelData):
    # ...
    frames: typing.Union[list[FrameMeta], none_type]

With standard PEP 484 notation:

class IDataMetaRead(IModelData):
    # ...
    frames: list[FrameMeta] | None # (or `Optional[list[FrameMeta]]` for broader compatibility)

Describe alternatives you've considered

Unfortunately, I haven't found a magic comment (e.g. # pyright: ignore, # type: ignore, etc.) that disables the type parsing failure. The inability for none_type = type(None) to be correctly resolved to the None singleton means type Unknown gets introduced and flows throughout usage of the cvat_sdk package. And introducing additional runtime code just to make static anayzers happy shouldn't be necessary, and it mostly doesn't work anyway. That Unknown is rather persistent once it's introduced.

Additional context

I've opened a related issue in the Pyright repo about how this technically-correct indirection isn't handled correctly. Rather than wait for them to accept it as a bug and fix it, I propose the cvat openapi-generator templates are updated to more modern syntax that is more static analyzer friendly.

[vivek41-glitch]

Hi! I'd like to work on this.

Before I start, I wanted to confirm:

1. Should the fix be applied to the auto-generated files directly, or to the OpenAPI generator templates?
2. Is there a preferred approach — | None or Optional[...]?

Happy to submit a PR once the approach is confirmed!

[rob3c]

I'm not a CVAT team member, so my opinion is unlikely to matter, but I appreciate your taking an interest. I'm using a modern python version and prefer the | None approach vs Optional[...], but I was just referencing the existing usage in the templates in my issue description. Maybe CVAT needs to support older python versions where the modern syntax isn't available.