build RPI3 artifacts

[Ludea]

What this PR does / why we need it:
Build Rpi3 artifacts

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1816

[mauromorales]

@jimmykarily @mudler I'm not sure how to decide on this one. On the one hand I think it's a good idea to have as many artifacts as possible so users can easily test Kairos, on the other hand this expands the time our CI will be running and besides wait time, we also see issues on release API hits. Also if we plan to have so many ARM builds, it might be a good idea to also consider ARM workers.

IMO the ideal scenario would be to know which artifacts are most interesting for users to consume and just build those, but we don't have any numbers so I guess we need to base the decision differently. Also soon there will also be rpi5 so we will end up with 3 times the artifacts for arm that we originally had, but we don't really know which of the boards is actually mostly used at any point in time.

This might be related to #1527

[mudler]

@jimmykarily @mudler I'm not sure how to decide on this one. On the one hand I think it's a good idea to have as many artifacts as possible so users can easily test Kairos, on the other hand this expands the time our CI will be running and besides wait time, we also see issues on release API hits. Also if we plan to have so many ARM builds, it might be a good idea to also consider ARM workers.

IMO the ideal scenario would be to know which artifacts are most interesting for users to consume and just build those, but we don't have any numbers so I guess we need to base the decision differently. Also soon there will also be rpi5 so we will end up with 3 times the artifacts for arm that we originally had, but we don't really know which of the boards is actually mostly used at any point in time.

This might be related to #1527

let's at least restrict the number of flavors we are going to support for RPI3 to the ones that are actually manually tested. Let's identify 1, or 2 of them that we can support for now. I'd tempted to say let's go alpine/openSUSE as alpine is small and openSUSE is well tested in our CIs (for amd64, but still). The other solution would be to use self-hosted runners and expand our CI's workers, but we might need to adapt the pipelines to make it work on self-hosted.

@Ludea would be fine with you?

[Ludea]

Perfect for me, I would like to use alpine

[mauromorales]

fantastic, thanks @Ludea for the contribution and @mudler for chipping in.