Update develop after v2.17.0

…cuts adjusted according to different Scopes, with the addition of Local Storage (#8186)

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

The intention was for this option to only be set in the production
requirements file, but due to how pip-compile-multi works, it ends up
leaking into all other files too. Moving it to the Dockerfile fixes
this.

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ts (#8369)

IMO, these checks are not very useful. The permission logic for requests
already checks that the request is being canceled by the same user that
created it. Therefore, these additional checks can only fail if a user
creates a request for some action, loses the permissions to do the same
action again, and then tries to cancel the request. But cancelling a
request does not do anything to the target resource (in fact, it
_prevents_ some future actions from taking place), so I really don't see
why this shouldn't be allowed.

In addition, these checks create some problems:

* If the creator of the request is no longer able to cancel it, we now
  have a request that _nobody_ is allowed to cancel. That seems wrong.

* To implement these checks, `RequestPermission` has to know which
  actions require which permissions. This creates code duplication between
  it and the other permission classes. It also causes a dependency on
  those classes, which could create problems if we want to use the request
  API for actions from the Enterprise version.

…sets`|`backups` (#8255)

- Fixed exporting the same dataset or backup twice in a row using
high-level SDK (switched to new export API version) (related
#8256)
- Fixed exporting a dataset or backup using high-level SDK when the
default project or task location refers to cloud storage
- Added ability to explicitly specify location when exporting datasets
and backups using high-level SDK

## Summary by CodeRabbit

- **New Features**
- Introduced mixins for exporting datasets and downloading backups,
enhancing functionality across multiple classes.
- Added a new fixture for testing tasks with specified target storage,
improving test coverage.

- **Bug Fixes**
- Improved error handling in the file download process to ensure
validity before proceeding.

- **Refactor**
- Restructured the downloading mechanism for better modularity and
maintainability.
- Removed outdated methods in favor of mixin functionality, streamlining
class design.

- **Tests**
- Enhanced the test suite with additional scenarios and flexibility for
task management and dataset downloading.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Maxim Zhiltsov <zhiltsov.max35@gmail.com>

#8378)

v3 is due to stop working on 2024-11-30:

<https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/>.

Note that `artifact-upload@v4` no longer allows multiple jobs of the
same workflow to upload an artifact with the same name, thus I had to
rename several of the artifacts. In the case of coverage results,
re-merge them at the end to avoid clutter on the workflow summary page.
I didn't bother with merging other artifacts, because they're only
produced in case of failure, so I'm not expecting them to create much
clutter.

Delete the schema upload step entirely, because I don't think it works
(it's inside the wrong job), and it doesn't seem that useful anyway.

GitHub Actions artifact storage is free for public repositories, so
there seems to be no reason to remove artifacts after builds.

<!-- Raise an issue to propose your change
(https://github.com/cvat-ai/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://docs.cvat.ai/docs/contributing/).
-->

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

### Motivation and context
By using tuple as a container for points when dealing with import from
datumaro, we can achieve 2 things:
- Reduce memory needed for copying shapes and tracks during import
(running `deepcopy` on `tuple[int]` will return the same object, as
opposed to `list[int]`)
- Guarantee type safety during later stages of data pipeline and skip
additional conversion added in #1898

Same thing arguable should be done for CVAT format as well.

Benchmarks:
[memray_reports.zip](https://github.com/user-attachments/files/16849509/memray_reports.zip)


### 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/cvat-ai/cvat/tree/develop/cvat-canvas#versioning),

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

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

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

### License

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


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **New Features**
- Improved handling of shape points during the import process for
enhanced data accuracy.
- Centralized conversion of shape points to floats, optimizing memory
usage and performance.

- **Refactor**
- Enhanced code readability and maintainability by restructuring the
point conversion logic.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

This will let us collect statistics about function usage.

Note that I would've preferred the function ID to go into the `obj_id`
field, but function IDs are strings, and the field is numeric.

<!-- Raise an issue to propose your change
(https://github.com/cvat-ai/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://docs.cvat.ai/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. -->
fixing #7783
also fixing related problem - some jobs from the issue can not be opened
in ui due to missing shapes

### 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! -->
- [ ] 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/cvat-ai/cvat/tree/develop/cvat-canvas#versioning),

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

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

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

### License

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


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **New Features**
- Enhanced data integrity in annotation processing by adding filtering
steps before sorting.
- New entries for "many jobs skeleton tracks with missing shapes" and
"many jobs skeleton" added to the dataset, improving job tracking
capabilities and complex job definitions.
- Introduced a new static method for annotation creation, improving code
modularity and reusability.

- **Bug Fixes**
- Improved error handling in annotation functions to prevent runtime
errors when accessing potentially undefined variables.

- **Tests**
- Expanded the testing framework with new tests for annotation creation
scenarios, ensuring comprehensive coverage.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

This has several goals:

* Remove `LambdaType.UNKNOWN`. Functions with this non-type are useless
  and should not be presented to the user.

* Don't return 404 from the list endpoint if one function cannot be
  loaded. This prevents one bad function from essentially disabling the
  entire serverless function feature. Instead, log the error and ignore
  the function.

* Don't return 404 from other endpoints either when the problem is a bad
  function. This is not a client problem. Raise an exception and let
  Django log it and return a 500.

* Remove HTTP codes from `LambdaFunction`, to improve separation of
  concerns.

This is consistent with other user-controllable objects, and when you're
triggering the API manually, makes it easier to determine which ID to
use.

This enum is used for a field named `kind` in a resource located at
`/api/lambda/function`, so it seems pretty clear that it should be named
`FunctionKind`. (Or perhaps `LambdaFunctionKind`, but I omitted the
"lambda" for consistency with views and serializers.)

In addition to renaming, move it to `models`, so that it can be used by
serializers. No such serializers currently exist, but I'd like to add
them later. Turn it into a Django choice enum as well, so that `__str__`
works out of the box.

Due to how `WebhookPermission.get_scopes` is written, any unhandled endpoint
will result in an empty list being returned, and thus no access control
being performed. This is the right thing for `/api/webhooks/events`, but not
so much for every other endpoint.