### Motivation and context
Resolved #3756
Resolved #5324

Used model is UBody via mmpose
https://mmpose.readthedocs.io/en/latest/model_zoo/wholebody_2d_keypoint.html#topdown-heatmap-hrnet-ubody-coco-wholebody-on-ubody2d

Optional: 
- [ ] Try different detectors from mmdetect
- [ ] GPU support (it very quick on CPU as well)

**Deploy with**: ```./deploy_cpu.sh pytorch/mmpose/ubody2d/nuclio/```

**Recommendations**: redeploy this list of functions if you use any of
them after using this code
 
- tensorflow/faster_rcnn_inception_v2_coco/nuclio/
- tensorflow/matterport/mask_rcnn/nuclio/
- pytorch/facebookresearch/detectron2/retinanet_r101/nuclio/
- openvino/omz/public/yolo-v3-tf/nuclio/
- onnx/WongKinYiu/yolov7/nuclio/
- openvino/omz/public/mask_rcnn_inception_resnet_v2_atrous_coco/nuclio/
-
openvino/omz/public/faster_rcnn_inception_resnet_v2_atrous_coco/nuclio/
- openvino/omz/intel/text-detection-0004/nuclio/
- openvino/omz/intel/semantic-segmentation-adas-0001/nuclio/
- openvino/omz/intel/face-detection-0205/nuclio/

Co-authored-by: cvat-bot[bot] <147643061+cvat-bot[bot]@users.noreply.github.com>

It's been deprecated in 3.12, and `fromtimestamp` is easier to use
anyway.

In addition, drop the pytz dependency, since the UTC time zone is
available in the standard library.

…ith cache enabled (#7087)

It's possible to get more than 1 GT job in a task in the case of
concurrent creation requests.
This PR fixes this by introducing a task row-level lock in the DB for
the update transaction.

- Fixed GT job creation race condition

Currently, Helm will delete the PVC when you uninstall your CVAT
release, which makes it easy to unintentionally lose data. Add a
`helm.sh/resource-policy` annotation to prevent that from happening.

This makes the data PVC consistent with the other PVCs created as part
of the Helm chart (ones belonging to PostgreSQL, KeyDB and Clickhouse),
which are also not deleted upon uninstall, albeit for a different
reason: they are created by the corresponding StatefulSets, and
StatefulSets retain their volumes when they are deleted.

<!-- Raise an issue to propose your change
(https://github.com/opencv/cvat/issues).
It helps to avoid duplication of efforts from multiple independent
contributors.
Discuss your ideas with maintainers to be sure that changes will be
approved and merged.
Read the [Contribution
guide](https://opencv.github.io/cvat/docs/contributing/). -->

<!-- Provide a general summary of your changes in the Title above -->

### Motivation and context
<!-- Why is this change required? What problem does it solve? If it
fixes an open
issue, please link to the issue here. Describe your changes in detail,
add
screenshots. -->

### How has this been tested?
<!-- Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc. -->

### Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply.
If an item isn't applicable for some reason, then ~~explicitly
strikethrough~~ the whole
line. If you don't do that, GitHub will show incorrect progress for the
pull request.
If you're unsure about any of these, don't hesitate to ask. We're here
to help! -->
- [x] I submit my changes into the `develop` branch
- [ ] I have created a changelog fragment <!-- see top comment in
CHANGELOG.md -->
- [ ] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
- [ ] I have linked related issues (see [GitHub docs](

https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword))
- [ ] I have increased versions of npm packages if it is necessary

([cvat-canvas](https://github.com/opencv/cvat/tree/develop/cvat-canvas#versioning),

[cvat-core](https://github.com/opencv/cvat/tree/develop/cvat-core#versioning),

[cvat-data](https://github.com/opencv/cvat/tree/develop/cvat-data#versioning)
and

[cvat-ui](https://github.com/opencv/cvat/tree/develop/cvat-ui#versioning))

### License

- [x] I submit _my code changes_ under the same [MIT License](
https://github.com/opencv/cvat/blob/develop/LICENSE) that covers the
project.
  Feel free to contact the maintainers if that's a concern.

…to two parts (#7084)

<!-- Raise an issue to propose your change
(https://github.com/opencv/cvat/issues).
It helps to avoid duplication of efforts from multiple independent
contributors.
Discuss your ideas with maintainers to be sure that changes will be
approved and merged.
Read the [Contribution
guide](https://opencv.github.io/cvat/docs/contributing/). -->

<!-- Provide a general summary of your changes in the Title above -->

### Motivation and context
<!-- Why is this change required? What problem does it solve? If it
fixes an open
issue, please link to the issue here. Describe your changes in detail,
add
screenshots. -->
The templates for the various backend service deployments differ in many
ways, but a lot of those differences can be eliminated. That way, it
becomes easier to compare different templates, to create new services,
and to make changes across all templates.

Specific differences which are eliminated are as follows:

* Different sets of values are used for customization. This can be
mitigated by putting the specific set of values in a local variable
once. That way, only the variable assignment needs to differ.

* Containers and volumes are named differently. There's no need for
this, since these names are local to a pod. Just name all analogous
containers/volumes the same thing.

* Some deployments use different values for the `app` label. This just
seems incorrect, since they all belong to the same app. Standardize on
`cvat-app` as the value.

* Some deployments forget to check disableDistinctCachePerService. That
seems like a bug.

* There are minor formatting differences.

Ideally I'd like to reduce these templates to just calling one big
shared template with service-specific parameters, but there are still
enough differences between the templates that I don't feel like doing
that just yet.

### How has this been tested?
<!-- Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc. -->
`helm template`

### Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply.
If an item isn't applicable for some reason, then ~~explicitly
strikethrough~~ the whole
line. If you don't do that, GitHub will show incorrect progress for the
pull request.
If you're unsure about any of these, don't hesitate to ask. We're here
to help! -->
- [x] I submit my changes into the `develop` branch
- ~~[ ] I have created a changelog fragment~~ <!-- see top comment in
CHANGELOG.md -->
- ~~[ ] I have updated the documentation accordingly~~
- ~~[ ] I have added tests to cover my changes~~
- ~~[ ] I have linked related issues (see [GitHub docs](

https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword))~~
- ~~[ ] I have increased versions of npm packages if it is necessary

([cvat-canvas](https://github.com/opencv/cvat/tree/develop/cvat-canvas#versioning),

[cvat-core](https://github.com/opencv/cvat/tree/develop/cvat-core#versioning),

[cvat-data](https://github.com/opencv/cvat/tree/develop/cvat-data#versioning)
and

[cvat-ui](https://github.com/opencv/cvat/tree/develop/cvat-ui#versioning))~~

### License

- [x] I submit _my code changes_ under the same [MIT License](
https://github.com/opencv/cvat/blob/develop/LICENSE) that covers the
project.
  Feel free to contact the maintainers if that's a concern.

…7148)

Since backend pods are all fairly similar, it stands to reason that
users would want to apply similar configuration to them. Add some
`cvat.backend.*` parameters that are applied to all backend
deployments/jobs.

Added:
- Generate ingress based on parameter `ingress: true/false`
- Ability to configure cvat hostname using an override value file
instead of the ugly --set option in helm
- Removed some deprecated ingress specifications

This will be useful for debugging issues and gathering statistics.

Use the JSON format, since that allows us to include more information
than the traditional HTTP access logs. Switch the other logs to JSON as
well, for ease of parsing.

The PR contains a REST API test that checks that a single user cannot
clog the import queue with his tasks.