Consider disallowing duplicate `Tag` keys for a single event.

[hjohn]

Currently, Axon Framework allows having multiple tags with the same key on an event (like course=1 and course=2). This is unusual usage, and we may want to investigate whether this is desirable. At a minimum, we could disallow this until there is a valid use case.

Related to this: tag keys are currently unrestricted, aside from disallowing null keys. We could reserve or disallow certain keys:

• The empty string (or any blank string)
• Keys with leading or trailing spaces
• Keys with a reserved prefix (_EVENT_NAME is reserved in Axon Server, we could consider reserving all keys starting with an underscore).

For values:

• The empty string (or any blank string)
• Values with leading or trailing spaces
• Values with an asterix (*) as this could be used to allow limited wild card matches (or glob patterns) as most engines can easily support this.
  • This could allow you to create criteria for events that simply are marked with a specific key (ie. key=*) or even partial matches (like location=Europe/*)

[MateuszNaKodach]

I would change the title to be about some Tag restrictions, because those you enumerated sounds more reasonable, a tleast to me.
Regarding duplicated TAG keys... I see use cases, let's say you do a group checkout in the hotel, and you can have event GroupChecketOut with all guests ids, then if you have particular guest operations, you source this event as well. Of course alternative it's to have N events with single tag value, instead of single event with N same tag values.

[hjohn]

I found out that @EventTag already has direct support for duplicate tags:

 * Special handling is provided for Iterable and Map:
 * <ul>
 *     <li>For {@link Iterable} values:
 *         <ul>
 *             <li>A separate tag is created for each non-null element in the iterable.</li>
 *             <li>All tags use the same key (from annotation or member name).</li>
 *             <li>The tag value is obtained by calling toString() on each element.</li>
 *             <li>Example: {@code @EventTag List<Integer> numbers = List.of(1, 2)} creates tags:
 *                 {@code Tag("numbers", "1")} and {@code Tag("numbers", "2")}</li>
 *         </ul>
 *     </li>

So I think that clinches it, we should just allow duplicate tags. We can still consider restricting the allowed keys/values though.