feat(api): support wildcard topic subscriptions

[Abdulmumin1]

Summary

adds support for wildcard patterns in destination topic subscriptions.

destinations can now subscribe to topic families using * inside a topic string, for example:

• user.*
• *.created
• order.*.completed

exact topic subscriptions keep the existing behavior, and "*" still means subscribe to all topics.

closes #908

Behavior

* inside a topic string matches any run of characters, separator-agnostic.

examples:

• user.* matches user.created
• user.* matches user.profile.updated
• *.created matches user.created and order.created
• order.*.completed matches order.payment.completed

published event topics are still exact topic strings. this only changes destination subscription matching/validation.

Validation

if available topics are configured, wildcard patterns must match at least one available topic.

for example, with available topics:

user.created
user.deleted

this is valid:

user.*

this is rejected:

order.*

if no available topics are configured, wildcard patterns are accepted, same as other destination topics today.

Implementation notes

topic matching is on the delivery hot path, so this avoids regex and avoids compiling/caching patterns.

the matcher uses a small allocation-free wildcard algorithm:

• exact strings still short-circuit
• * matches any run of characters
• matching is separator-agnostic
• benchmark coverage was added for exact match/miss and pattern match/miss

Tests

verified with local test infra running:

TESTINFRA=1 go test ./internal/publishmq -run 'TestEventHandler|TestIntegrationPublishMQEventHandler_Concurrency' -count=1

TESTINFRA=1 go test ./internal/models ./internal/tenantstore/memtenantstore ./internal/tenantstore/redistenantstore ./internal/apirouter ./internal/publishmq -count=1

bench:

TESTINFRA=1 go test ./internal/models -bench 'BenchmarkTopics_MatchTopic' -benchmem -run '^$'

result on my machine:

Benchmark	Time	Bytes/op	Allocs/op
BenchmarkTopicsMatchTopic/exactmatch-8	34.26 ns/op	0 B/op	0 allocs/op
BenchmarkTopicsMatchTopic/exactmiss-8	30.93 ns/op	0 B/op	0 allocs/op
BenchmarkTopicsMatchTopic/patternmatch-8	77.37 ns/op	0 B/op	0 allocs/op
BenchmarkTopicsMatchTopic/patternmiss-8	93.08 ns/op	0 B/op	0 allocs/op

[alexluong]

Heya, overall looks great and we should be quite close!

A few notes

1: I see we're not changing the portal (internal/portal) yet. Do you intend for that to be out of scope of this PR?
2: There's this case on the List Destination API where we can run GET /tenants/X/destinations?topics=user.created. I wonder what the behavior for this should be with wildcard support.
3: We should add tests to make sure destination with wildcard topics will be matched properly in event delivery (via /publish). I can also help commit the test for this if you prefer.

[Abdulmumin1]

awesome @alexluong about the portal stuff.. i think i might let the team decide on how the ui would evolve. as @alexbouchardd pointed out. the current topic input can't really accommodate it cleanly.

i might play around with something.. but i'm not going to be making any decisions on that

[alexbouchardd]

You can maybe map the top-level User checkbox to user.*. In which case, manually selecting all "children" wouldn't select the parent. Selecting the parent could then use a wildcard? Maybe that's too subtle though

A bigger issue with just ignoring it is that the UI may break if the user uses the API to set their topics with a wildcard and then later loads the UI