first draft for concurrency using an approach at the database level

[J0nasMayr]

Changes:

• Fix pod-concurrency using db-level atomic compare-and-set
• Add exponential backoff logic for failing sends with a threshold of maximum tries
• make public facing sendOrFail not retry on failure
• Refactor entity Email adding new fields and embedding logically connected ones

[J0nasMayr]

@SirCotare I think the approach I went with here fits better than com.translog.transcon.job.DistributedLockService since we are talking about a single job here which is sending emails. In this case the locking granularity should be per row, not per job. Using com.translog.transcon.job.DistributedLockService we would have to have a distinct lockKey for each email (i.e. we would have to add the Email-id to the lockKey). That would require each scheduled run of sending nqueued emails to create/hold n locks. I do not think that that is very clean/performant.
If you think that I should go with it anyways, just say the word.

[mmalfertheiner]

• Followup task: The Cleanup scheduler is not yet multi pod safe

[J0nasMayr]

@mmalfertheiner Andreas and I agreed to have a try-catch block in case the .save() fails because in that case we cannot do anything anyways. The actual email-send and the .save() after to set the mail to something other than SENDING will always be independent statements and hence if the .save() fails we cannot do any more than logging it...

[mmalfertheiner]

Well done! LGTM