mgmt: hawkbit: use SMF

[maass-hamburg]

Use the State Machine Framework for hawkBit. Includes a lot of cleanup of the hawkBit subsystem.

Resolves: #71576
Resolves: #71691
Resolves: #71759

Depends on/the following PRs should be merged before this:

• mgmt: hawkbit: make server address and port settable during runtime #68806
• mgmt: hawkbit: define attributes in the user application #69293
• mgmt: hawkbit: correct ddi api calls #70386
• mgmt: hawkbit: autohandler and shell optimize #71037
• lib: smf: make number of arguments constant for SMF_CREATE_STATE() #71250
• kernel: implement k_realloc #72483

the commits from before mgmt: hawkbit: use SMF are from #71037

this is a WIP

[kartben]

cc @glenn-andrews

[glenn-andrews]

Consider transitioning to an error-handling state rather than using smf_set_state(SMF_CTX(s), NULL);

[real-tintin]

This is great! We have considered rewriting the implementation to use a state machine due to multiple issue (I previously wrote in the roadmap issue). As I wrote there, we have made adaptions and bug fixes e.g., issues with double freeing and handling of NULL response (crashes hard during download if not checked). But I see that you have improved on the malloc and I strongly believe that the SMF will solve a bunch of issues itself.

I would like to give this a try. I will merge (locally for testing) our adaptions e.g., a dynamic config e.g., setting endpoints and tokens (during a device provisioning over BLE) - I saw that it already exist a PR for a similar change.

[maass-hamburg]

This is great! We have considered rewriting the implementation to use a state machine due to multiple issue (I previously wrote in the roadmap issue). As I wrote there, we have made adaptions and bug fixes e.g., issues with double freeing and handling of NULL response (crashes hard during download if not checked). But I see that you have improved on the malloc and I strongly believe that the SMF will solve a bunch of issues itself.

I would like to give this a try. I will merge (locally for testing) our adaptions e.g., a dynamic config e.g., setting endpoints and tokens (during a device provisioning over BLE) - I saw that it already exist a PR for a similar change.

Thanks for the feedback!
If you find bugs, please feel free to open an issue. And if you have a fix for it, it would be wonderful if you contribute it back into the zephyr main. It makes thinks easier for all of us.

The same is true for new features, feel free to contribute. Just look at the features we added to hawkBit in the last weeks: here

[real-tintin]

Hi! What is the status of this? Is it possible to get this into the 3.7 release? FYI, we have already rolled this out in our prod and done rigorous real-world-testing prior to it.

[maass-hamburg]

Hi! What is the status of this? Is it possible to get this into the 3.7 release? FYI, we have already rolled this out in our prod and done rigorous real-world-testing prior to it.

If #71037 gets approved and merged, we could start with this.

@ycsin what do you think?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[real-tintin]

@glenn-andrews what is your opinion on this? I would very much see that this is merged. Huge improvement to the current implementation.