Reading JMSTimestamp from an 'amqp' destination results in exception

[l-k-test]

This is very similar to #112:

Invoking javax.jms.Message.getJMSTimestamp() results in the following exception:

java.lang.NumberFormatException: Null is not a valid long
at com.rabbitmq.jms.client.RMQMessage.getLongProperty(RMQMessage.java:501)
at com.rabbitmq.jms.client.RMQMessage.getJMSTimestamp(RMQMessage.java:245)
at...

[acogoluegnes]

The message timestamp is not mandatory in AMQP 0-9-1, so this is why it is not set in the converted JMS message. Not an excuse to crash though. The JMS timestamp is set on the sender side but this can be disabled with MessageProducer#setDisableMessageTimestamp(boolean) and the specification suggests that consumed messages have then a timestamp of 0. This is the behavior we should adopt here. Does that sound OK?

As a reference, the 3.4.4 section of the specification:

The JMSTimestamp header field contains the time a message was handed off to
a provider to be sent. It is not the time the message was actually transmitted
because the actual send may occur later due to transactions or other client side
queueing of messages.

When a message is sent, JMSTimestamp is ignored. When the send method
returns it contains a a time value somewhere in the interval between the call
and the return. It is in the format of a normal Java millis time value.

Since timestamps take some effort to create and increase a message’s size, some
JMS providers may be able to optimize message overhead if they are given a
hint that timestamp is not used by an application. JMS MessageProducer
provides a hint to disable timestamps. When a client sets a producer to disable
timestamps it is saying that it does not depend on the value of timestamp for
the messages it produces. These messages must either have timestamp set to
zero or, if the hint is ignored, timestamp must be set to its normal value.

[l-k-test]

Yes, it looks perfectly within the JMS specification.