chore: use signed commits when publishing packages through Lerna

[fnesveda]

When publishing new versions of packages, Lerna doesn't sign the commit in which it bumps the versions. Once we enforce commit signing everywhere, this would break.

This PR fixes it by not pushing the commit created by the publication, but rather recreating it through the signed-commit action. It also merges the publication and changelog sync into one commit.

[l2ysho]

LGTM

my only concern is lerna itself. We had a problem few days ago with drift between tag of a package and real package version pushed to npm (#649 we were pointing to version which not existed) and I am not sure if this pipe can now recover if lerna publish fail (restart probably fails on pushing tags? ). Maybe we can do lerna stuff first and then sign?

[fnesveda]

I think the workflow will be able to recover, because of the way lerna publish from-package works. The scenario would be:

1. First workflow run
   i. lerna version is called, versions get bumped in package.jsons, comitted and pushed
   ii. lerna publish from-package is called, but fails, so there is a drift between code and NPM
2. Second workflow run
   i. lerna version is called, but there are no new changes since the first workflow run, so no versions get bumped
   ii. lerna publish from-package is called, it checks whether the versions in package.jsons are present in NPM, it sees that they're not, so it publishes them

[fnesveda]

@B4nan if you could also take a look, I'd be glad. I think we'll need to use this approach in other repositories with Lerna, like Crawlee, so I'd like more eyes on this.

[B4nan]

Do we really need this? I mean, lerna has --sign-git-commit and --sign-git-tag flags, also this might work universally:

git config --global commit.gpgsign true
git config --global tag.gpgsign true

[fnesveda]

Do we really need this? I mean, lerna has --sign-git-commit and --sign-git-tag flags, also this might work universally:

git config --global commit.gpgsign true
git config --global tag.gpgsign true

That means we'd have to have a signing key in the repo secrets, which could leak, and it would be pretty hard to track down if it did.

This way we can push signed commits with an API token, which we can (and eventually will) generate through a GitHub app, so that it's temporary.