Edge event table - added sequential ID column to handle properly heavy load and cluster cases

[volodymyr-babak]

Pull Request description

Motivation: This pull request addresses two potential issues that could arise from improper message delivery to the edge, particularly under heavy load or in cluster mode.

The 'edge_event' table is currently processed by sorting via the 'createdTime' column. Under heavy load, it's possible for multiple events to have identical 'createdTime' values. In such cases, some events might be missed and not sent to the edge under certain conditions, or conversely, some events might be sent twice.

In cluster mode, 'createdTime' is generated on a specific cluster node. If there is a time difference between nodes, or if there are issues in the steps to save events, resulting in delayed delivery, certain events can be missed and not delivered to the edge.

To resolve these issues, a new sequential column has been added to the 'edge_event' table. This column will be used to track which events have already been sent and which are yet to be delivered. By using this approach, PostgreSQL becomes the single point for generating this sequence number, even in the case of cluster mode.

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.