Consider refactoring how default shard agent is set in kargo_instance

[eddiewebb]

Prior to version 0.9.8 the kargo_instance required an agent ID for the value of spec.kargo_instance_spec.default_shard_agent. This worked, but only on update, as during creation there was a circular dependency because the agent to reference needed the instance ID to be created.

1. create instance without default
2. Create agent with instance ID
3. Update Terraform to include the previously created agent's ID in the instance config.
4. re-run terraform apply

In 0.9.8 the field was updated to accept an agent name, eliminating terraform cyclic error. However on attempts to use the new approach the kargo_instance just hangs, stuck in the 'progresssing' stage. It seems to fail as the instance is specifying a default_shard_agent by name that does not exist yet.

,"error":"failed to build data values for KargoInstance with id b7gsw33a5i8fw10r: failed to get default shard agent: sql: no rows in result 

I think we will need to mimic the UI flow for initial creation, which is to move the selection of default shard agent into the agent itself. This will let an instance be provisioned without any default, provide an instance ID that an agent needs to be provisioned, and set itself as the default on creation.

This will shift some consideration on the operator to make sure in the case of multiple agents, that only one is nominating itself as default, but hopefully some reasonable error handling can assist that potential conflict just as we do in the UI.

[hanxiaop]

https://github.com/akuity/terraform-provider-akp/releases/tag/v0.9.9 has been released with the improvement.