Free pyblijuju from relying on juju client when connecting to a controller

[cderici]

Description

This moves the computation of the controller_name from the connector to the Controller class, to be lazily evaluated from jujudata (and cached). We can move it out of the connector safely because:

1 - controller_name is not used within the connector.
2 - the only location that the controller_name is returned to, ignores it.

This has the nice consequence of freeing pylibjuju from relying on things like the controllers.yaml file (in turn the juju client to be installed) to connect to a controller.

Fixes #983

QA Steps

Added a test for lazy computation of controller_name.

 $ tox -e integration -- tests/integration/test_controller.py::test_connection_lazy_jujudata

But the scenario from the #983 can be tried easily as follows:

# make a new controller and connect it in a normal way:
from juju import controller
c = controller.Controller()
await c.connect()

# get the connection
conn = c.connection()

Now go move the .local/share/juju/controllers.yaml file temporarily.

# make a new controller
c2 = controller.Controller()

# connect it using the information within the connection we got above
await c2.connect(endpoint=conn.endpoints[0][0], cacert=conn.cacert, username=conn.usertag, password=conn.password)

Should succeed without any errors.

Don't forget to move back your controllers.yaml back so nothing else on your machine freaks out.

All CI tests need to pass.

Notes & Discussion

juju-4891

[jack-w-shaw]

LGTM

[cderici]

CI fails are unrelated, @jack-w-shaw if you wanna tackle a bitesize thing, only a charm change would fix this one.

[cderici]

/merge