preventing placeholder hosts from draining worker console logs

[brettsam]

Issue describing the changes in this PR

Resolves #10222 and #9360

During specialization, there can be a race to process logs being generated by the placeholder worker. If a worker writes console output during startup (say, during a file load like the issue describes), the placeholder can dequeue these and log them, which effectively means they go nowhere.

This change prevents placeholder hosts from dequeuing these messages at all, so they are ready to be consumed by the user's host starting up.

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

[kshyju]

Do we need to add an entry to release notes for this change?

[surgupta-msft]

As mentioned in this issue - #9360, can this be a breaking change as users will start receiving logs which they were not getting before? Some logs will be errors/warnings and can have sensitive information as part of exception details (which can be a separate issue to fix but calling it out). Do we need to inform css about this as there could be more CRIs when users see additional errors/warnings in their appInsights?

[brettsam]

@surgupta-msft -- good question. I wouldn't consider this a breaking change because the behavior isn't really changing today -- the problem is that during specialization, some logs disappeared.

But w/o specialization, it all worked (which is why it was tough to repro initially) -- so some customers would sometimes see these logs and other times not, depending on the specialization.

So i'd consider this a "fix" to make it consistently appear, even during specialization