Making message properties accessible while handling/consuming the message

[manojsharma27]

The existing implementation does provide a way of pushing meta-info as part of headers via message properties, but there is no support of accessing these headers while consuming and processing the message in the application's actor.

Moreover, it is not just headers, several useful meta-info like correlation Id, appId, clusterId, etc which are present in AMQP.BasicProperties are possible to publish with the message but can't be leveraged during processing the message.

This PR fixes the same thing and exposes message properties to the actor's handle method via MessageMetadata.

Sample Usage:

  actors:
    TEST_ACTOR:
      exchange: test-exchg
      delayed: false
      prefix: testService
      concurrency: 1
      prefetchCount: 1
      retryConfig:
        type: COUNT_LIMITED_EXPONENTIAL_BACKOFF
        maxAttempts: 6
        multipier: 50
        maxTimeBetweenRetries: 30s
      messageMetaGeneratorClasses:
        - io.appform.dropwizard.actors.actor.metadata.MessageReDeliveredMetaGenerator
        - io.appform.dropwizard.actors.actor.metadata.MessageDelayMetaGenerator
        - io.appform.dropwizard.actors.actor.metadata.MessageExpiredMetaGenerator

With this change, devs are open to create their custom metadata generators and use them as per need.

[santanusinha]

This makes testing difficult. Do not create objects using constructors in other constructors if possible

[santanusinha]

val or remove variable

[santanusinha]

val

[santanusinha]

I do not like this naming of classes in config. If we ever refactor code, every single config will break in existing clients. If a discovery is needed, it is better to create an annotation like @MetaGenerator("REDELIVERY_META_GENERATOR") which can be annotated on the meta generator class. At the initialization of the bundle we can use Reflections to discover all such generators and validate them against what has been provided in config.
Your config also becomes like this:

  actors:
    TEST_ACTOR:
      exchange: test-exchg
      delayed: false
      prefix: testService
      concurrency: 1
      prefetchCount: 1
      retryConfig:
        type: COUNT_LIMITED_EXPONENTIAL_BACKOFF
        maxAttempts: 6
        multipier: 50
        maxTimeBetweenRetries: 30s
      messageMetaGeneratorClasses:
        - REDELIVERY_META_GENERATOR
        - DELAY_META_GENERATOR
        - EXPIRED_META_GENERATOR

Pros:

• Simplifies config
• Makes config immune to code refactors later on
  Cons:
• Potentially slower startup due to classpath scanning (Can be mitigated by taking a reflections object in as param somehere in bundle init, if the client software is already creating one for some reason)

Implementer Note

• Must throw if two meta-gen classes are named the same

[santanusinha]

@r0goyal this needs more reviews