fix(snap): drive the snap release workflow to avoid skipping tagged versions

[cjdcordeiro]

Fixes #300.

This PR addresses the issue described in #300. It includes the following changes:

• instead of relying on the store to build the snaps, the GH workflow uses remote-build to drive the multi-arch builds,
• the snapcraft.yaml parts were updated in order to be supported by the remote-build environment,
• added a new trigger, on push,
• the resulting multi-arch snaps are uploaded to the snap store on every new GH release and push to master,
• on every new GH release, it now simply takes the latest snap from edge to candidate,
• finally, we apply concurrency to ensure 2 consecutive commits won't result in older snaps becoming the "latest" in the snap store.

Before merging

1. disconnect this repository from the Pebble snap "Builds" in the snap store
2. add the following new secrets to the repo (thus why the CI is failing for this PR):

• LP_CREDENTIALS (new and already shared with the team)
• PEBBLE_DEV_MAILING_LIST (already shared with the team in the past)

---

This has been tested in: https://github.com/cjdcordeiro/pebble/actions/runs/6505676433 and https://github.com/cjdcordeiro/pebble/actions/runs/6505679630

[benhoyt]

Excellent! I was hoping to see this before the next release. :-)

I haven't used snapcraft, but this looks good overall to me.

[jnsgruk]

I've added the credentials to the repo, disconnected from the snapcraft.io build service - I've just retriggered the CI to ensure that it passes before merging.

[cjdcordeiro]

It seems like the job is not picking up on the LP_CREDENTIALS secret

  echo '' > ${lp_creds_path}/credentials

[jnsgruk]

No I think that's just because it doesn't include sensitive values in the log output :) I'm not sure what happened here, there is definitely a secret named LP_CREDENTIALS in place now

[cjdcordeiro]

When it's a secret GH will printout *** in lieu of the variable. Example -> https://github.com/cjdcordeiro/pebble/actions/runs/6505676433/job/17669768265

In this case, it didn't read anything. Can you check the repository's workflow permissions?

[jnsgruk]

Closing this PR in favour of #322