Discovery / rule handling at reconnects

There is the possibility to have an undefined behavior regarding subscription (via a rule set).

**Precondition:**
1. Platform is running
2. **Talent A** has been started
3. **Talent A** discovered by platform (subscribes **Event X** via its rule set)
4. **Event X** is send
5. **Talent A** receives **Event X** => Everything correct so far

**Undefined behavior state:**

6. Restart **Talent A** which wants to subscribe to **Event Z** (so fast, that no discovery happens in between)
7. **Event X** is send
8. **Talent A** receives **Event X** based on the old rule-set **=> Undefined behavior!!!**
9. **Talent A** discovered by platform (subscribes **Event Z** via its rule set)
10. **Event X** and **Event Z** is send
11. **Talent A** receives **Event X** (not **Event Z** anymore) => From now on, everything is right

So, the issue is that the old rule-sets from Talent A's previous discovery is still active (platform doesn't know that Talent A has not been restarted). In case of different rule-sets this leads to undefined behavior, because Talent A can receive some unknown events.

**Ideas to fix it:**

- Use an 'instance-uuid' for each talent instance which is related to the rule set. If the instance uuid won't fix (e.g. after a re-start of the talent
- Can be message based --> add this uuid to the (event) messages and filter them out if the instance uuid is not correct
- Can be topic based --> uuid is part of the topic which is subscribed and won't receive events from a previous instance topic
- State management on Talent side --> If it has not been discovered before it it is in a "disconnected" state and will wait until the defined behavior is established. (This might be not cover all circumstances)