fix: change mdcoverage url for getCurrentApiVersion

[shetzel]

What does this PR do?

Changes the URL to get an API version from https://mdcoverage.secure.force.com/services/apexrest/report to https://dx-extended-coverage.my.salesforce-sites.com/services/data
If neither sourceApiVersion nor apiVersion were set on a ComponentSet before calling getObject(), will then look for and use (in order):

1. sourceApiVersion set in sfdx-project.json
2. apiVersion from ConfigAggregator (config files and Env Vars)
3. http call to /services/data endpoint for highest apiVersion
4. hardcoded value of "58.0" as a last resort

What issues does this PR fix or reference?

@W-14621701@

[mshanemc]

comment is nit.

I'd suggest recommend an FYI to VSCode team about this change--they should be doing apiVersion stuff already. I just know they've had some issues in the past around these Singleton and cwd patterns in the past when they have long-running processes. Give Pete's folks something else to test.

[diyer]

why version 58.0 as default?

[shetzel]

I just chose a recent one. It's better than throwing an error. We really should never get to this point. ComponentSets should have apiVersion and sourceApiVersion set by the consumer.

[diyer]

At some point version 58.0 will be too old and things may not function as expected on this version. In that case does it make sense to throw an error vs using a default value that is old?

[shetzel]

The code will warn with the missingApiVersion message should it ever get to this point and use v58.0, so if an end user sees this message they can do things to get better results should it fail. If we throw, they will definitely need to do something to get it to work. Both Shane and I felt that doing what we could to not fail is better.

In practice, the checks for an API version should never get past the sourceApiVersion and apiVersion set on the ComponentSet. If users of SDR are creating ComponentSets without setting a sourceApiVersion and/or apiVersion then they shouldn't be creating a manifest from it.

[mshanemc]

If we're taking that approach, maybe https://org62.my.salesforce-sites.com/services/data would be more reliable/scalable than this team's endpoint.

or use Promise.any of several known URLs

[mshanemc]

QA (using the node REPL)

> const csb = require('./lib/src/collections/componentSetBuilder.js').ComponentSetBuilder
undefined
> const result = await csb.build({sourcepath: ['./test/nuts/local/replacements/testProj/force-app']})
undefined
> const pkg = await result.getPackageXml()
undefined
> pkg

✅ has ' <version>59.0</version>\n' +
[turns off internet]

> const pkg2 = await result.getPackageXml()
undefined
> pkg2

✅ defaulted to v58 ' 58.0\n' +