Blazor Web project interactive options improvements. Rename render modes.

[SteveSandersonMS]

Fixes #50433 (Add root level interactivity option)
Fixes #50646 (Remove workaround for Counter component)
Fixes #50636 (Clarify the names of the interactive render modes)

In terms of the code we now emit, there should be nothing controversial here. The template just has to do quite a bit of if/else in many places to account for all these options and how rendermodes are used and not used based on them.

The PR is big because the renames have really wide impact, but almost all the "files changes" are just due to renames. The only real code changes are in the project templates.

Testing impact

Adding this option, the BlazorWeb template now has so many possible combinations of options, including:

• Whether or not to enable Server interactivity
• Whether or not to enable WebAssembly interactivity
• Whether or not to be interactive from the root
• Whether or not to include sample content
• Whether or not to use ProgramMain

So that's around 32 combinations of output - without even accounting for auth options! We don't currently have E2E verification of any of them, as those tests are skipped due to unreliability. We're going to have to lean hard on CTI validations for this, and make sure all the important combinations are covered - cc @mkArtakMSFT.

Options design update

Having a list of 6 separate checkboxes in VS is pretty unpleasant and hard to understand:

So, in this PR I'm proposing (and have implemented, but we can still change it), a change to use dropdowns for the interactivity type and location options. This reduces the number of inputs by one, and means they can be more self-describing:

• The "interactivity type" choices are:
  • None
  • Server (default)
  • WebAssembly
  • Auto (Server and WebAssembly).
• The "interactivity location" choices are:
  • Per page/component (default)
  • Global

Note that "interactivity location" is disabled if interactivity type == "None", but only CLI honors that right now (VS should add support later, and until then, location will have no effect if there's no interactivity).

I think this is much easier to understand, since you no longer have to infer that enabling both Server and WebAssembly means you're going to get Auto. It's also much better in the CLI, since it was completely ridiculous before that --use-server defaulted to true but --use-wasm defaulted to false, so to get WebAssembly you needed to set --use-server false --use wasm. Now you would say --interactivity webassembly (and not wasm - that was weird too).

[danroth27]

Love the new UX! It's way better than the flat list of check boxes.

[mkArtakMSFT]

So this was a bug we didn't notice in the past then?

[SteveSandersonMS]

It was a weird inconsistency but didn't impact the test actually working correctly. I think the Template string is only used for reporting in logs, and doesn't affect whether the test passes or fails, or which template gets executed.

[davidfowl]

These names don't look very nice... I don't have an alternative yet but these feel very verbose and not that much more clear.

[SteveSandersonMS]

These names don't look very nice... I don't have an alternative yet but these feel very verbose and not that much more clear.

Since you mention verbosity, I'm guessing you're referring to the CLI names (inside the VS wizard, verbosity is not much of a consideration).

So, regarding CLI names, Dan and I discussed:

• For "interactive at root" on the CLI (--all-interactive), we tried out various ideas but didn't find anything that seemed both clearer and more succinct. The most literal equivalent to the VS phrasing would be --interactivity-location global but that's way too long. If anyone comes up with an improved name we're happy to change to it.
• For "interactivity type" on the CLI, we renamed from --interactivity to --interactive, so the usage will be --interactive webassembly or --interactive auto or --interactive none or --interactive server (the latter being default). We think this feels pretty good, and uses exactly the terminology developers and our docs all use already.

[SteveSandersonMS]

Update: we can't use the parameter name --interactive because that's a reserved alias. I've set it back to --interactivity.