feat: create new jujud controller binary

[iyiguncevik]

Creates a separate jujud controller binary by cloning cmd/jujuagentd/ to cmd/jujud/ as an independent Go package. This binary will become the controller application, packaged as the juju-controller snap.

---

Changes

New package: cmd/jujud/

• Copied from cmd/jujuagentd/ with all import paths updated to cmd/jujud
• Binary name: jujud (via SuperCommand Name field)
• Logger prefix: juju.cmd.jujud
• Dispatch case uses names.JujuController
• Tool path references use names.JujuController
• Initially has identical manifold wiring to jujuagentd (steps 3 & 4 will diverge them)

juju/names/names.go

• Added JujuController = "jujud" constant
• Renamed Jujud → JujuAgentd and JujudVersions → JujuVersions for clarity
• All references across the codebase updated accordingly

Makefile

• Added jujud to BUILD_CGO_AGENT_TARGETS, INSTALL_TARGETS (linux only)
• Added .PHONY jujud install target and ${BUILD_DIR}/%/bin/jujud build target
• Both require CGO, dqlite, and libsqlite3 build tags
• jujud is not added to simplestreams packaging (distributed via snap only)

External references

• cmd/package_test.go: added jujud to ignored packages
• scripts/engine-dag/main.go: added cmd/jujud/agent/{machine,model} imports with --agent flag
• cmd/containeragent/unit/package_test.go: added cmd/jujud/agent/* entries

---

Out of scope

• Removing machine-agent manifolds (step 3)
• Gating out-of-scope manifolds (step 4)
• Snap packaging / CAAS Dockerfile changes

Checklist

• Code style: imports ordered, good names, simple structure, etc
• Comments saying why design decisions were made
• Go unit tests, with comments saying what you're testing
• Integration tests, with comments saying what you're testing
• doc.go added or updated in changed packages

QA steps

Verify bootstrap is still working fine:

❯ juju bootstrap lxd src --build-agent

❯ jst -m controller
Model       Controller  Cloud/Region  Version      Timestamp
controller  src         lxd/default   4.1-beta2.1  17:48:52+02:00

App         Version  Status  Scale  Charm            Channel     Rev  Exposed  Message
controller           active      1  juju-controller  4.1/stable  157  no

Unit           Workload  Agent  Machine  Public address  Ports            Message
controller/0*  active    idle   0        10.159.202.172  17022,17070/tcp

Machine  State    Address         Inst id        Base          AZ      Message
0        started  10.159.202.172  juju-a2b1c8-0  ubuntu@24.04  tuxedo  Running

Relation provider     Requirer              Interface  Type  Message
controller:dbcluster  controller:dbcluster  dbcluster  peer

❯ juju ssh -m controller 0 -- ps -ef | grep juju
root        5879       1  0 15:42 ?        00:00:00 bash /etc/systemd/system/jujuagentd-machine-0-exec-start.sh
root        5883    5879  0 15:42 ?        00:00:02 /var/lib/juju/tools/machine-0/jujuagentd machine --data-dir /var/lib/juju --machine-id 0 --debug

Documentation changes

Links

Jira card: JUJU-9706

[SimonRichardson]

Follow ups:

1. Do we want two versions for jujud and jujuagentd? I don't think we do want to do that, but we should explore this.
2. Versions of the agent and the controller will mismatch during an upgrade or via misconfigured setups, which I know we're not trying to solve yet, but we should keep a note. We should prevent an jujuagentd being able to be to talk to jujud that is lower version than itself. That sort of misconfiguration might be dangerous.

[SimonRichardson]

We'll know this works when this becomes the following:

Suggested change

	${run_cgo_install}
	${run_go_install}