The `dora up` command always starts a coordinator and daemon in local mode using the default config. For non-standard config and for remote setups, users need to use `dora coordinator` and `dora daemon` directly.

This way, the default address is shown as part of the `--help` output.

Make dora cli connect to remote coordinator

Signed-off-by: Gege-Wang <2891067867@qq.com>

fix: localhost to control_socket_addr()

We want to treat the nodes like custom nodes in this case since we plan to deprecate operators.

We plan to (soft-)remove operators and simplify the dataflow YAML file by removing the additional nesting caused by the `custom` field. This commit prepares for that. See #474 for context.

It might take a short time until the daemon is connected to the coordinator after start-up. This could lead to issues when using `dora up` in a script because a subsequent `dora start` command might fail when the daemon is not connected at that point.

This commit fixes this issue by waiting until the coordinator confirms that a daemon is connected before returning from `dora up`.

Avoids a cargo warning.

This reverts commit 4af82a4833.

clients can not connect to `0.0.0.0` on windows.

Ref: #459

Ref: #459

This commit makes it possible to specify the conda env that we want to use in
a specific operator.

```yaml
  - id: robot
    operator:
      python:
        source: ../operators/robot.py
        conda_env: robomaster
```

This will call:
```bash
conda run -n robomaster python -c "import dora; dora.start_runtime()"
```

Bump 0.3.2-rc2

This commit make it possible to check the logs as follows:

```bash
dora logs object_detection
```

If more than one dataflow is running, we will inquire for which dataflow to use.

Fix window path error

Simplify operator template and remove type hinting

beautify graph visualisation