[dhvani7014]

Fixes #6890

Adds a KEDA scaler mapping for ActiveMQ Artemis queues, following the keda-scaler contributing guide.

• pkg/trait/keda/scalers/artemis.go: registers a mapper for the amqp component (the URI ArkMQ bindings produce, amqp:queue:<name>). It maps the queue name to queueName and brokerAddress for the KEDA artemis-queue scaler. Topics are not mapped. managementEndpoint and brokerName can't be derived from the URI, so they are provided via keda.autoMetadata.
• artemis_test.go: unit tests for registration, mapping, and MapToKedaTrigger, modelled on kafka_test.go.
• e2e: added a KEDA auto-discovery test to the ArkMQ suite (Pipe from my-queue with autoMetadata), and installed KEDA in the ArkMQ setup script.

Tested locally with go test ./pkg/trait/keda/... ./pkg/trait, gofmt, and go vet -tags integration ./e2e/arkmq/. I couldn't run the e2e test locally.

The e2e test checks the generated ScaledObject (auto-discovery + metadata merge), like the Kafka auto-discovery test. Happy to extend it to a full scale-up/scale-down test if you'd like.

[squakez]

I think the main goal is to be able to discover the endpoint automatically. I think you can use a Pipe and see how it converts into an Integration DSL. From the Integration you can verify the camel parameters and map them into the scaler accordingly.

[dhvani7014]

Thanks @squakez! I checked the Pipe → Integration conversion: the ArkMQ binding produces amqp:queue:my-queue plus the camel.component.amqp.broker-url property. I'm planning to let the KEDA mapper read camel.component.<scheme>.* properties so the artemis scaler can derive managementEndpoint from the broker URL host + port 8161.

A few questions before I push:

1. Should the endpoint be the headless service host or the pod FQDN (<cr>-ss-0...), given the Jolokia origin check?
2. Is it ok to default brokerName to amq-broker, or keep it in autoMetadata?
3. Since auto-discovered triggers can't carry the console credentials, is a ScaledObject-only e2e check enough for this PR?

[squakez]

Thanks @squakez! I checked the Pipe → Integration conversion: the ArkMQ binding produces amqp:queue:my-queue plus the camel.component.amqp.broker-url property. I'm planning to let the KEDA mapper read camel.component.<scheme>.* properties so the artemis scaler can derive managementEndpoint from the broker URL host + port 8161.

A few questions before I push:

1. Should the endpoint be the headless service host or the pod FQDN (`<cr>-ss-0...`), given the Jolokia origin check?

2. Is it ok to default `brokerName` to `amq-broker`, or keep it in `autoMetadata`?

3. Since auto-discovered triggers can't carry the console credentials, is a ScaledObject-only e2e check enough for this PR?

It could be a good idea to also use application properties to extract mapping configuration. However it may require some change in the original architecture to pass a new map to the scaler. Feel free to provide some proposal. The host should be the one coming from the configuration (mind that it could even be an Integration, not only a Pipe). Any other parameter has to be recovered automatically from the Integration as well as credential if they are present. However, given this is a first implementation you may let the credentials setting out of the implementation.

A good sample to get some inspiration is in the e2e Kafka scaler test. We should try to replicate the same logic, but using the new scaler instead.