add region check

[nammn]

Checklist

• Checked if it requires a pylibjuju change?
• Added integration tests for the PR?
• Added or updated doc.go related to packages changed?
• Do comments answer the question of why design decisions were made?

---

Description of change

See the code comment on the place for further reference.
One PR added that we always have at least an empty region in the clouds.yaml. The code, in the past, checked for each region invalid endpoints.
Those endpoints do not get called for clouds not "supporting" them.

QA steps

~/golang/src/juiu/juju/acceptancetests/assess_add_cloud.py ~/cloud-city/example-clouds.yaml ~/golang/bin/juju

e.g. output

Expected fail (bug #1641970): bogus-auth-canonistack, long-endpoint-canonistack, long-endpoint-canonistack-lcy01, long-endpoint-canonistack-lcy02, long-endpoint-finfolk-vmaas
Expected fail (bug #1641981): numeral-prefix-canonistack, numeral-prefix-finfolk-vmaas, slash-in-name-canonistack, slash-in-name-finfolk-vmaas
Failed: none

[SimonRichardson]

I'm approving this test, but we should work on improving this test, so that it interacts with the CLI to gain the knowledge it needs. Using the clouds.yml is shortsighted, although you can check that it's actually stored in the yaml, the point of this test is to check that juju knows about regions. This should be exposed via the CLI and then uses the CLI as a normal user would. Skipping the latter shows that there could be a gap for operators.

I think we should use juju regions <cloud> --format=json to get what we want!

[nammn]

@SimonRichardson I agree on using the CLI. I would suggest postponing it to another PR though, as this would touch the client library and therefore touch more than we eventually want to check for now.

$$merge$$

[nammn]

$$merge$$