Remove temporary desktop plugin dartPluginClass workaround

[stuartmorgan]

On 1.18 (current master), desktop plugins can either specify a pluginClass for a standard plugin with native code, or a dartPluginClass to allow that platform's implementation of a plugin to be Dart-only. However, the current stable build, 1.17, doesn't have this logic, and requires a pluginClass for all desktop platforms. When building for any platform, all platforms listed in the pubspec are validated, which means that publishing a plugin with:

  plugin:
    platforms:
        dartPluginClass: Foo

will break the iOS and Android builds of any project that ends up with a dependency on that plugin. That means that for example we can't publish a Dart-only Linux implementation of path_provider and endorse it without breaking everyone on stable.

To work around this, I propose temporarily adding special handling to the desktop platforms where having pluginClass: none is treated the same way as having no pluginClass field. This will pass validation on 1.17, but be a no-op on master. The workaround would be removed once 1.18 is released to stable.

Minor downsides:

• Desktop builds with older versions of master will break when using one of these plugins. It's master though, so it's reasonable to say that you need to be using the latest version if you want to use published plugins on desktop.
• If someone is building on desktop using another channel and bypassing our check (e.g., changing to a local branch at the same revision but a different name) they will break when using one of these plugins. However, that's not a supported configuration, so I'm fine with that tradeoff. Someone who really wants to do this can always patch their local copy with the workaround, or pin to a version of the plugin that doesn't endorse a plugin using this.

[stuartmorgan]

The proposal above was added; this issue now tracks removing the workaround. This is two-phase:

• Remove pluginClass: none from the plugins
• Remove the special handling of none from flutter_tools

We should likely leave a while between those steps, since the second will break anyone still building with a version of the plugin from before step 1.

[stuartmorgan]

This will require all of the relevant plugins to require 1.20+. That's something that also came up with regard to removing the iOS stubs from all the non-iOS federated plugins.

@amirh Is there any existing plan to mass-upgrade the requirements for flutter/plugins? If not, what's the best way to drive that discussion?

[stuartmorgan]

We're no longer using it in flutter/plugins. We should eventually remove the special-casing, but there's no hurry on it and it's a breaking change.