Handle MessageExpiryInterval early enough for retained messages to honor it

[dariopb]

Setting the pk.Expiry member to the right value early enough so it is correctly saved when the message is retained in RetainMessage.

Without the change, even if we set the MessageExpiryInterval for retained message, the message won't expire at that interval since it was stored already with the default value (0) for pk.Expiry.

[thedevop]

Thank you @dariopb for the PR. The identification of the issue is correct. In reviewing this, I found we're not providing consistent behavior when MaximumMessageExpiryInterval is set to 0. So we may need to make larger modifications.
@mochi-co, currently when MaximumMessageExpiryInterval is set to 0, sometimes the server behaves as

1. no limit
   

   server/server.go

   Lines 1714 to 1717 in 8f52b89

   	// If the maximum message expiry interval is set (greater than 0), and the message
   	// retention period exceeds the maximum expiry, the message will be forcibly removed.
   	enforced := s.Options.Capabilities.MaximumMessageExpiryInterval > 0 &&
   	now-pk.Created > s.Options.Capabilities.MaximumMessageExpiryInterval

2. yet sometimes it treats as expire immediately
   

   server/server.go

   Lines 989 to 992 in 8f52b89

   	pk.Expiry = pk.Created + s.Options.Capabilities.MaximumMessageExpiryInterval
   	if pk.Properties.MessageExpiryInterval > 0 {
   	pk.Expiry = pk.Created + int64(pk.Properties.MessageExpiryInterval)
   	}

Which meaning do you prefer?

[mochi-co]

@thedevop I think if we are to look at it logically, then 0 should be expire immediately. We can always set an very high expiry (maxint), but we cannot otherwise set expire immediately (unless we set it to 1 and then there's a short delay).

If 1 expires after 1, then 0 should expire immediately I think. What do you think?

[coveralls]

Pull Request Test Coverage Report for Build 12403881253

Details

• 7 of 9 (77.78%) changed or added relevant lines in 1 file are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.1%) to 98.498%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
server.go	7	9	77.78%

Files with Coverage Reduction	New Missed Lines	%
server.go	4	98.7%

Totals
Change from base Build 11487320372:	-0.1%
Covered Lines:	6165
Relevant Lines:	6259

---

💛 - Coveralls

[thedevop]

Ok, so when MaximumMessageExpiryInterval is 0, it means expire immediately. We can use MaxInt to make it effectively unlimited if needed.

@dariopb, let me know if you can make the the corresponding changes in this PR or I can submit a separate PR.

[thedevop]

@mochi-co, looking at this further, we will create conflicts if we define define MaximumMessageExpiryInterval == 0 as expire immediately. We have the following:

1. pk.Properties.MessageExpiryInterval:
2. pk.Expiry
3. MaximumMessageExpiryInterval

According to MQTTv5 spec, when a message doesn't have expiry, it should not expire. When the message received does't have expiry set, then currently pk.Properties.MessageExpiryInterval is 0, to mean message doesn't expire. If we allow MessageExpiryInterval == 0 to mean expire immediately, it will create conflict.

Currently pk.Expiry == 0 also means no expiration. So if we change that to mean expire immediately, then effectively we will also be setting pk.Properties.MessageExpiryInterval to 0 for outgoing messages.

Now if we define MaximumMessageExpiryInterval == 0 as expire immediately, it can result in pk.Expiry set as 0, create a conflict.

So to be consistent. we should define MaximumMessageExpiryInterval == 0 as no expiration limit.

I have created a new PR that:

1. Address @dariopb's issue
2. Only set pk.Expiry if pk.Properties.MessageExpiryInterval or MaximumMessageExpiryInterval is not zero-value
3. Ensure outgoing pk.Properties.MessageExpiryInterval doesn't contain uint32(of negative value or zero-value) by setting a minimum of 1