@iSazonov ready to review!

EDIT: I lied, but now codefactor stuff is fixed.

I wonder how many code you update. 😄 I expect you add only content output.

I like you create helper methods. But now output is too large and we must generate the output only it is requested.
I don't find method(s) to check the condition and we could create it here.
For start see how internal void WriteDebug(DebugRecord record, bool overrideInquire = false) does the check.
We can get ((MshCommandRuntime)this.CommandRuntime).DebugPreference and reuse code from internal bool WriteHelper_ShouldWrite
(All in src\System.Management.Automation\engine\MshCommandRuntime.cs)

The same for verbose. But I wouldn't waste time on verbose right now at all. But it's up to you.

Also I'd prefer to use standard TosString() for request and response. Why do we create custom implementation?

@iSazonov I had this discussion with @SeeminglyScience on discord and it is noted there isn't an ideal reliable way to check preference (if you check the first commit I was testing for it prior) and he recommended not establishing it as a pattern but rather this should be something the runtime provides as part of the PSCmdlet abstract class.

In testing the code has a non-visible impact even on large payloads if Verbose/Debug aren't specified.

I moved away from the Request/Response message toString in order to match the format as noted, and reduce redundant information between Verbose and Debug. I put the user experience in favor of the direct implementation. We can revert that if required, but I would lobby for this, especially since I try/catch potential edge cases (haven't hit any so far in testing)

EDIT: Also I made very sure not to alter existing Webcmdlet behavior, the additional areas I changed were just additive where they made sense in context, I'm very aware this is some hot-path stuff and I'm keeping the scope just to the output aspects.

@JustinGrote Yes, we haven't std methods for the checks. I think it's important to have them because later we can add even more output (for example certificates)
One way is to create them. So I open #25514. If you could ask him in Discord to review it, that would be great.
Another way is to use simple workaround only for interactive scenario. We could check switches by more reliable way than you did - Debug.IsPresent/Verbose.IsPresent. We could use this if my PR will be blocked/rejected.

Sounds good. Do we want to merge this PR as-is for the next preview and add the conditional logic later, or wait for #25514?

Let's wait for what Patrick says. If that PR is not approved, then let's look at switch checks. What I definitely would not like is to create these strings without a condition.
We can discuss the details for now.

@iSazonov thank you for the review, I will incorporate the recently merged PR and your feedback hopefully sometime this week.

@iSazonov feedback incorporated and it is now conditional using the new internal IsEnabled checks

@iSazonov changes requested implemented (I went with a nested foreach for the headers to make that easier to read), and made CodeFactor happy. I also squash rebased to a single commit so this should be mergeable now. Let me know any further issues.

@iSazonov static refactor reverted. CodeFactor however is now complaining about complex methods I didn't touch. I tried a rebase/reset and confirmed I didn't touch those methods as far as I can tell. Any idea what's going on? Is it the nullable maybe?

@iSazonov tests fixed (at least locally on my machine), the -Debug parameter was causing inquire and since Pester is run interactively, was waiting on the dialog, switched to using debugpreference.

Also adjusted encoding test to match on Codepage since we are providing it anyways, should be a much less brittle test.

@JustinGrote Still hang. I guess VerbosePreference is inquire.

Probably related to this, I couldn't get it to reproduce in Linux but let me do it in Windows.

This is still active, there's an issue somewhere in the MaximumRetry code where a request is getting reused, I haven't been able to track it down yet and need to step thru the commits to find where it's happening.

@iSazonov I found the problem. Please approve for tests to run, it should fully pass now and be mergeable.

LGTM with one notice: perhaps it makes sense to remove body from debug output because it can be too large..

It is a possibility with text-based responses, but most extremely large responses will be binary that will be summarized.

I will suggest we merge as is and if feedback shows that it is a constant problem, we either add a fixed or user-configurable truncation option.

@iSazonov is there a reason the linux/windows AzDevOps CI are pending? I don't have any visibility that I know of.

/azp run PowerShell-CI-linux-packaging,PowerShell-Windows-Packaging-CI

@JustinGrote Many thanks!

@iSazonov same to you!