Adjustments for SqlMainDomLock and others to make azure operations more resilient

[Shazwazza]

Details are here: #8215

This should also resolve #8392

• Improvements to SqlMainDomLock
  • Better management of db instances and transactions - previously this was trying to manage a single database instances which isn't what should be done, db instances should exist for a short period of time and disposed of. Changed to more explicit code for managing transactions
  • Increase polling times - though according to logs this wasn't causing problems but is still too aggressive for what it's doing
  • Don't stop listening (shut down maindom) if there are SQL exceptions, only if the appdomain has actually triggered a shutdown. We cannot just stop listening even if there are errors since it will lead to premature MainDom shutdown when the app is not actually being shutdown. This means it will just retry on the next poll.
• Investigation into scheduled publishing lock request timeouts (also reported here Scheduled content leads to SQL error when rebuilding cache  #8392) which occurs around the same time as when SqlMainDomLock fails
  • The PerformScheduledPublishInternal was using yield returns with a wrapped Scope/IDisposable which is a bit hard to follow along. One issue is that we were yield returning when the Saving event was canceled for an individual item but not continuing so the logic would have proceeded anyways for that item even if that event was canceled and found other similar issues where it would actually break out of the entire process instead of skip to the next record
  • I believe one of the main issues seen with the lock request timeouts like those in Scheduled content leads to SQL error when rebuilding cache  #8392 and in the logs for 8.6.1 - Azure Web App - Indexes disappear completely #8215 is because the PerformScheduledPublishInternal takes a WriteLock at the very beginning of the method. This is the write lock that times out according to the stack traces. This is probably because scheduled publishing runs every minute which is actually a bit crazy to think we lock the whole content tree every minute even if we aren't writing anything. And because of that I think this may also be one of the other main suspects as to why we saw SqlMainDomLock error around the same time we see the sql lock timeout error for scheduled publishing. To fix this:
    • We need a new and much faster method: DocumentRepository.HasContentForRelease instead of only relying on the potentially expensive DocumentRepository.GetContentForRelease, similarly for GetContentForExpiration we should also have HasContentForExpiration. Then we separate the job of PerformScheduledPublishInternal into 2 parts: First, without any read or write locks just check if either HasContentForRelease or GetContentForExpiration is true, then we can take a write lock and proceed as we are today. This will mean that there isn't a writelock on all content attempted to be made every minute.
• Don't short circuit index rebuilding if one of the populators throws an exception, continue with the other populators
• Brings our sql transient fault handling in-line with the latest specs from MS

[bergmania]

Changes looks good, and makes sense due to your description..

Only thing I don't understand/think is intentional, is the delete of the ssl-port