Device job deploy v2 improvements

[Coduz]

This PR introduces a bunch of improvements for the Job Engine to work properly with async package management service.

Related Issue
None

Description of the solution adopted
Now the NotificationMessage listener checks also for job to be restarted for a target that has completed the Package install

Screenshots
None

Any side note on the changes made
Javadoc and small code improvements applied.

[codecov]

Codecov Report

Merging #2524 into develop will increase coverage by 5.69%.
The diff coverage is 13.79%.

@@              Coverage Diff              @@
##             develop    #2524      +/-   ##
=============================================
+ Coverage      50.23%   55.93%   +5.69%     
+ Complexity      2453     1502     -951     
=============================================
  Files            958     1073     +115     
  Lines          27553    25955    -1598     
  Branches        2261     2332      +71     
=============================================
+ Hits           13842    14517     +675     
+ Misses         12732    10450    -2282     
- Partials         979      988       +9

Impacted Files	Coverage Δ	Complexity Δ
...ua/service/job/targets/internal/JobTargetImpl.java	55.17% <ø> (+48.27%)	10 <0> (+9)	⬆️
...kapua/service/job/targets/JobTargetAttributes.java	0% <ø> (ø)	0 <0> (?)
.../DeviceManagementNotificationMessageProcessor.java	0% <0%> (ø)	0 <0> (ø)	⬇️
...pse/kapua/service/job/targets/JobTargetStatus.java	100% <100%> (ø)	1 <0> (?)
...ons/model/AbstractKapuaUpdatableEntityCreator.java	30% <14.28%> (-27.15%)	0 <0> (ø)
...atastore/internal/model/StorableIdFactoryImpl.java	0% <0%> (-100%)	0% <0%> (-2%)
...e/authentication/token/AccessTokenXmlRegistry.java	0% <0%> (-60%)	0% <0%> (ø)
...rnal/model/query/StorablePredicateFactoryImpl.java	28.57% <0%> (-42.86%)	0% <0%> (-5%)
...pse/kapua/service/authorization/domain/Domain.java	0% <0%> (-40%)	0% <0%> (ø)
.../kapua/commons/model/AbstractKapuaNamedEntity.java	76.47% <0%> (-23.53%)	0% <0%> (ø)
... and 426 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35b78c3...879ba8c. Read the comment docs.

[stefanomorson]

After reviewing the work in this PR a possible improvement emerged. It is described here below.

When a long running operation is executed, there is a limited possibility that some unsolicited messages sent by the device in order to notify the progress are delivered before the operation execution returns.
As a consequence, if the operation was invoked by a device job, the notification handler is not able to address the correct job in order to update its status and trigger execution of the next job steps.
This is currently solved in the job business logic by passing a unique id as a parameter for
the operation execution. While this works it exposes the client code to more complexity
that is related to implementation details.

Instead of passing the id in, the job should wait until the execution of the operation returns passing back the id of the operation registry to the job. Possible notifications received from the device while the operation execution was in progress, are already logged and persisted in the operation-registry-notification table so they can be used by the job to recover the "missed" notifications.
After the operation execution returns, the job should use the id of the operation registry to retrieve the notifications already collected from the operation-registry-notification table and use them to update the job: update the progress and trigger execution of the next job steps (e.g. enqueuing job executions).