[ci]: Fix auto-labeling

[s8sato]

Description

• Fix: api-changes config-changes auto-labeling
• Refactor: merge the above and iroha2 into one workflow
• Feature: notify someone specific based on the above auto-labels
• Feature: add another group of auto-labels to categorize PRs based on title

Linked issue

• Closes Automatic notification about config.json changes through CI #4278

Benefits

• Make PR labels easier to handle
• Reduce workflows by one

Checklist

• I've read CONTRIBUTING.md
• I've used the standard signed-off commit format (or will squash just before merging)
• All applicable CI checks pass (or I promised to make them pass later)
• (optional) I've written unit tests for the code changes
• I replied to all comments after code review, marking all implemented changes with thumbs up

[0x009922]

Can we wait with merging of this until the merge of #4239? That PR changes the approach to the config itself. Actually, after the 2.0 release there should NOT be breaking changes in the config and we should establish a clear deprecation and migration policy.

[BAStos525]

From my side, it would be better to be notified via PR auto-assignment or just auto-comment with my username because it's better rather than to search for PRs with config-changed label. Smth like that:

permissions:
  pull-requests: write
jobs:
  api-changes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: jitterbit/get-changed-files@v1
        continue-on-error: true
        id: api_label
      - uses: actions-ecosystem/action-add-labels@v1
        if: contains(steps.api_label.outputs.added_modified, 'docs/source/references/schema.json')
        with:
          github_token: ${{ secrets.github_token }}
          labels: |
            api-changes
      - uses: mshick/add-pr-comment@v2
        if: contains(steps.api_label.outputs.added_modified, 'docs/source/references/schema.json')
        with:
          message: @BAStos525 

But I understand that we should'n bind CI within any particular person.

[coveralls]

Pull Request Test Coverage Report for Build 7987011957

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2964 unchanged lines in 53 files lost coverage.
• Overall coverage decreased (-0.3%) to 56.509%

---

Files with Coverage Reduction	New Missed Lines	%
core/src/sumeragi/network_topology.rs	1	98.78%
tools/kagami/src/crypto.rs	1	12.12%
data_model/src/metadata.rs	2	78.87%
primitives/src/unique_vec.rs	2	91.24%
config/src/kura.rs	3	80.0%
config/src/logger.rs	5	72.73%
logger/src/lib.rs	5	94.12%
tools/kagami/src/main.rs	5	0.0%
crypto/src/signature/secp256k1.rs	7	96.09%
telemetry/src/dev.rs	7	0.0%

Totals
Change from base Build 7884695009:	-0.3%
Covered Lines:	22413
Relevant Lines:	39663

---

💛 - Coveralls

[s8sato]

#4276 (comment)

Yeah, for now this PR is only intended to add clues to detect configuration changes.
Here are 2 other suggestions for making notifications actually work.
Do you think the following would work as well as your suggestion @BAStos525 ?

1. Have a separate workflow dedicated to managing individual notifications for labeling, including manual labeling
   • https://github.com/marketplace/actions/issue-label-notifier
2. Have each person have web hooks to receive notifications
   • https://github.com/bcongdon/github-label-notify

But before that, we have yet to see CI label config-changes in response to mock config changes in this PR

[BAStos525]

#4276 (comment)

Yeah, for now this PR is only intended to add clues to detect configuration changes. Here are 2 other suggestions for making notifications actually work. Do you think the followings would work as well as your suggestion @BAStos525 ?

1. Have a separate workflow dedicated to managing individual notifications for labeling, including manual labeling

   • https://github.com/marketplace/actions/issue-label-notifier

2. Have each person have web hooks to receive notifications

   • https://github.com/bcongdon/github-label-notify

But before that, we have yet to see CI label config-changes in response to mock config changes in this PR

We will think about it later. I want say that we should try to avoid creating a new workflows for tiny tasks whatever it's possible.

[s8sato]

This PR itself cannot trigger the changed workflows since pull_request_target event-driven workflows are based on the code of the base branch (hyperledger:iroha2-dev)
https://github.com/actions/labeler?tab=readme-ov-file#initial-set-up-of-the-labeler-action