@MessageConsumer for discovery

Replace the JMS 2.1 proposed `JMSMessageDrivenBean` with an annotation, tentatively called `@MessageConsumer`

# Background

JMS 2.1 proposed a `JMSMessageDrivenBean` interface which would be implemented by the MDB to allow the bean to be mapped to a Connector per the Connector 1.7 rules for no-interface views.

The Connector 1.7 rules require the Connector Provider to supply an interface with no methods and specify it as the message listener interface. The proposed `JMSMessageDrivenBean` would have been specified by the JMS RA (Connector) in the ra.xml file as follows:

```

javax.jms.JMSMessageDrivenBean

```

A bean developer would then implement this no-method interface so that it could have the ability to use the new annotation-based JMS 2.1 API. For example:

```
import javax.annotation.Resource;
import javax.ejb.MessageDriven;
import javax.jms.ConnectionFactory;
import javax.jms.JMSContext;
import javax.jms.JMSException;
import javax.jms.JMSMessageDrivenBean;
import javax.jms.JMSProducer;
import javax.jms.JMSRuntimeException;
import javax.jms.MessageHeader;
import javax.jms.ObjectMessage;
import javax.jms.QueueListener;
import javax.jms.Topic;

@MessageDriven
public class BuildAndNotify implements JMSMessageDrivenBean {

@Resource
private ConnectionFactory connectionFactory;

@QueueListener("PROJECT.BUILD")
public void buildProject(@MessageHeader(MessageHeader.Header.JMSReplyTo) final Topic buildNotifications,
@MessageHeader(MessageHeader.Header.JMSCorrelationID) final String buildId,
final ObjectMessage objectMessage) throws JMSException {
// ...
}
}
```

## Issues

While functional, this solution is a bit awkward:

- Implementing a no-method interface is not natural outside old APIs like `java.io.Serializable`

# Proposal

As annotations are essentially interfaces, the proposal is to update the Connector specification such that the `` may be either an `interface` or an `@interface` (annotation). When the type is an annotation, this shall be deemed to function identically to the Connector 1.7 no-interface view.

For Jakarta Messaging the implication is that the proposed `JMSMessageDrivenBean` interface could be replaced with an annotation, such as `MessageConsumer`:

```
package jakarta.jms;

import javax.resource.spi.ConnectorDrivenBean;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import static java.lang.annotation.ElementType.ANNOTATION_TYPE;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

/**
* This annotation replaces the proposed JMSMessageDrivenBean interface
*/
@Retention(RUNTIME)
@Target({ANNOTATION_TYPE, TYPE})
@ConnectorDrivenBean
public @interface MessageConsumer {
}
```

A bean developer could use that annotation as follows:

```
@MessageConsumer
public class BuildAndNotify {

@Resource
private ConnectionFactory connectionFactory;

@QueueListener("PROJECT.BUILD")
public void buildProject(@MessageHeader(MessageHeader.Header.JMSReplyTo) final Topic buildNotifications,
@MessageHeader(MessageHeader.Header.JMSCorrelationID) final String buildId,
final ObjectMessage objectMessage) throws JMSException {
// ...
}
}
```

## Benefits

- More natural to developers to specify what is effectively metadata, as an annotation rather than an interface.
- Consistent with other APIs like JAX-RS's `@Path`
- Opens the door for an approach that might be more CDI-friendly

The issue names no repository files, tests, or entry points. Start by reviewing the proposed Connector specification change and the Jakarta Messaging MessageConsumer annotation shown in the issue. Done means resolving the annotation-versus-interface design and defining the resulting API and specification changes.

Written by the indexing model from the issue text.