Pull Request description

https://thingsboard-portal.atlassian.net/jira/software/c/projects/PROD/boards/33?assignee=5dd3fc93b63a210fb4b6b1c2&selectedIssue=PROD-6936

Fix: Duplicate Resource Read Requests During Client Registration
Problem:

During the client registration process, the system was sending duplicate read requests for resources. This occurred because we were sending read requests twice: once for attributes and telemetry, and a second time for observations. This led to unnecessary network traffic and increased the load on the LwM2M client.

Solution:

This pull request addresses the issue by implementing a new, more efficient strategy for sending read requests during client registration.

Prioritize Observation Requests: The process now first sends a request to observe all required resources.

Smart Read Requests: After the observation requests are sent, the system sends a separate batch of read requests for attributes and telemetry. A key improvement is that if a resource is already included in the observation request, a duplicate read request is not sent.

New Registration Strategy: We have introduced a new strategy for sending read requests during registration. This new strategy mirrors the logic used for observation requests, ensuring that the entire process is more streamlined and prevents redundant communication with the device.

These changes ensure that all necessary resource data is retrieved efficiently without any duplicate requests, significantly improving the performance and reliability of the client registration process.

General checklist

• You have reviewed the guidelines document.
• Labels that classify your pull request have been added.
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.
• Similar PR is opened for PE version to simplify merge. Crosslinks between PRs added. Required for internal contributors only.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.
• Ensure new API is documented here

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.
• If new service was added: the service is marked with corresponding @TbCoreComponent, @TbRuleEngineComponent, @TbTransportComponent, etc.
• If new REST API was added: the RestClient.java was updated, issue for Python REST client is created.
• If new yml property was added: make sure a description is added (above or near the property).