fix a signal subscription creation bug

[robert-gurol-ebcont]

Fixes a bug where for the second process you start, signal event processing would happen differently.
E.g., the scope would always be null for the second process (unless the BPMN model cache runs out in the mean time).

Affects Flowable 6.8.1, 7.0.1

Workaround without this fix:
Signal ID and name must be the same, e.g.
<bpmn:signal id="terminate_product" name="terminate_product" flowable:scope="processInstance" />

Check List:

• Unit tests: YES / NO / NA
  • (as stated elsewhere, I would like to add some, but I need a bit of help getting started - e.g. a pointer to existing test classes that I could extend with 1 or two test cases)
• Documentation: NA
  • (should not be necessary for a simple bugfix)

[robert-gurol-ebcont]

TODOs

• check if any unit tests fail
  • if yes, check if this is not a bug, but a feature
    • if feature, reconsider MR
    • if bug, adjust unit test
  • if not, add own unit test(s)
    • Migration:
      • migrate 2 process instances with Signal definitions that have a non-null flowable:scope
      • check that both processes' event subscriptions have a non-null configuration (scope)
    • Process start:
      • start 2 process instances with Signal definitions that have a non-null flowable:scope
      • check that both processes' event subscriptions have a non-null configuration (scope)
    • ℹ️ I created an issue where I ask for help to get started

EDIT:

• goes through: mvn clean install -DskipTests -DskipITs
• goes through: mvn verify -pl modules/flowable-engine
[WARNING] Tests run: 3681, Failures: 0, Errors: 0, Skipped: 6

[tijsrademakers]

Thank you for the PR, but there are no unit tests showing what this fixes exactly. Therefore closing the PR. Please create a new PR with unit tests if you would like to get this reopened.