FIX: Type definitions to allow passing meta object as second parameter

[andrewimeson]

Prior to this it would only work if you did

NewDnsProvider("bind","BIND" {"stuff": "stuff"})

But it wouldn't support omitting the optional provider type and specifying the extra object.

NewDnsProvider("bind", {"stuff": "stuff"})

Fixes #3946

[andrewimeson]

Downside: This does make the hinting less useful for NewDnsProvider().

Maybe there's another way to solve this.

[tlimoncelli]

A half-baked thought:

What if the parameters/parameter_types only reflected the modern style (NewDnsProvider("bind", {"stuff": "stuff"}) and NewDnsProvider("bind")). The code would still support the old style (NewDnsProvider("bind", "BIND", {"stuff": "stuff"}) and the docs could have a section that explains that that format works but should be updated.

While I'm always concerned about backwards compatibility, I have little sympathy for people that have been ignoring a warning for more than a year. They've been getting warnings that look like this:

INFO: In dnsconfig.js NewDnsProvider("foo", "BAR") can be simplified to NewDnsProvider("foo") (See https://docs.dnscontrol.org/commands/creds-json#cleanup)

The docs say "Starting with v4.0 support for the OLD format may be reported as an error." I forgot I wrote that. We should probably do that soon. (Note to self: Also add a warning when the 2nd parameter is "-").

Bottom line: I'm fine with the types-dnscontrol.d.ts file only showing the modern style.

[andrewimeson]

@tlimoncelli I think that makes a lot of sense. The type hints should be best-effort at supporting deprecated-but-not-yet-removed syntax.

[tlimoncelli]

Looks good! Could you add a section to documentation/language-reference/top-level-functions/NewDnsProvider.md called # Backwards Compatibility that explains that if you see NewDnsProvider("foo" ,"-" or NewDnsProvider("foo", "PROVIDERNAME this is older syntax that is going away soon. "preview" will print warnings telling you what to change.