[engine] Fix some type hints when request is passed

[Marishka17]

Motivation and context

Since we are adding custom attributes to the request object (such as uuid or iam_context), using the Request type is no longer appropriate.
Based on #9075

How has this been tested?

Checklist

• I submit my changes into the develop branch
  - [ ] I have created a changelog fragment
  - [ ] I have updated the documentation accordingly
  - [ ] I have added tests to cover my changes
  - [ ] I have linked related issues (see GitHub docs)

License

• I submit my code changes under the same MIT License that covers the project.
  Feel free to contact the maintainers if that's a concern.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 99.29078% with 1 line in your changes missing coverage. Please review.

Project coverage is 73.93%. Comparing base (df5678a) to head (0667d47).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #9077      +/-   ##
===========================================
+ Coverage    73.91%   73.93%   +0.01%     
===========================================
  Files          428      429       +1     
  Lines        44530    44546      +16     
  Branches      3881     3881              
===========================================
+ Hits         32916    32934      +18     
+ Misses       11614    11612       -2     

Components	Coverage Δ
cvat-ui	77.45% <ø> (+<0.01%)	⬆️
cvat-server	71.02% <99.29%> (+0.01%)	⬆️

[SpecLad]

I think PatchedRequest gives off the wrong idea. "Patched" implies some sort of change, but we only add new attributes. How about something like ExtendedRequest or AugmentedRequest?

[zhiltsov-max]

How about just engine.types.Request?

[SpecLad]

How about just engine.types.Request?

IMO, it's too ambiguous. But if both you and @Marishka17 prefer it, I'm not going to object.

[zhiltsov-max]

I mean, it should be something like HttpRequest or ApiRequest, but we need to avoid confusion with other requests we already have, such as function requests or async operation requests. I'm not sure this module (called types) is a good place for such an abstraction, maybe it should be something server API or http related (e.g. we already have view_uitls).

[SpecLad]

HttpRequest would be ambiguous too (since it's the name of the base Django type).

[zhiltsov-max]

What is the point of inclusion of Extended in the name? Imagine a situation where there is a private app with some new middleware, which also adds some new fields. I don't think ExtendedExtendedAPIRequest would be a good name for that updated request type. That's why I suggested using something problem-oriented, like HttpRequest (which we already have in Django) or ApiRequest. Extended just doesn't add much, it's better to use a type with the same name as the base type, just defined in a properly named module. It's likely that we'll use it in most places in the code. If we want to switch type annotations to an updated HttpRequest in all the APIs, we can do this by using from cvat.apps.some_speaking_module_name import HttpRequest. In fact, this engine's HttpRequest could already be inherited from a IAM's HttpRequest with the necessary fields added, and which could be used in relevant type annotations in IAM, because it is the module contract and scope (IAM isn't supposed to depend on engine and it uses engine in just 1 place).

[SpecLad]

What is the point of inclusion of Extended in the name?

To give my two cents: it's to make the name more descriptive. It's like Request, but, well... extended. It makes it clear to someone reading the codebase that it's not the original Request type, but is compatible with it.

Admittedly, it doesn't say much about how the type was extended, but neither does ApiRequest. 🤷

I don't think ExtendedExtendedAPIRequest would be a good name for that updated request type.

It could be EnterpriseExtendedRequest.

---

@Marishka17 What name do you prefer?

[zhiltsov-max]

If you want a distinct name, it could also be CoreHttpRequest.

[Marishka17]

What name do you prefer?

I'm no longer code owner to give my preferences :)
Initially I would have prefer to use ExtendedRequest just because I know that original type was Request from rest framework. But if it "intersects" with the names in our logic and it isn't clear what it extends, let's use what do you or Maxim say.

[SpecLad]

I'm the one who suggested ExtendedRequest, so I'm obviously fine with it. That's two of us against one, so I'm going to go ahead and merge this. It's an internal type, so we can always rename it if needed.

[sonarqubecloud]

Quality Gate passed

Issues
19 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud