[BUG] Deadloop for duplicated configuration

[peter-jerry-ye]

Affected project(s)

• documentation
• examples
• wasmCloud host
• wasmCloud CLI (wash)
• wasmCloud dashboard UI (washboard)
• capability providers
• provider bindgen
• control interface client
• other / not sure

Describe the bug

(I'm not sure if it's the problem with wadm or wasmcloud host but) if there are two configurations sharing the same name for the same link, there will be a dead loop.

Steps to reproduce

Define an application where a link has a configuration with the same name

Expected behavior

I would expect to see some error / warning, instead of logging insanely putting configuration etc.

Environment

• OS: MacOS
• Shell: zsh
• wasmcloud Version:

wash          v0.36.1
├ nats-server v2.10.20
├ wadm        v0.18.0
└ wasmcloud   v1.4.0

Screenshots / Logs / Additional context

[brooksmtownsend]

I think there's two ways to solve this issue, one of which is really easy to just put in place (which is why I marked this as good-first-issue) and then the second would be a bit more involved but likely a good change to make.

First off, I think it would be a good idea to add an additional manifest validation function that ensures that configuration names don't conflict from within a single manifest. Including this in the validation code makes sure that an application with duplicated config names would be denied at put time, e.g. before it is even deployed. This should be pretty simple and is the good-first-issue bit. That function should be called here https://github.com/wasmCloud/wadm/blob/main/crates/wadm-types/src/validation.rs#L324

Second, I think it would be good to enhance the BackoffWrapper to not just backoff for a few seconds on failed events, but also backoff exponentially from publishing commands at all. It's possible that a scaler would need to send a series of sequential commands to properly reconcile, but in this case where a configuration scaler is just deadlooping, backing off would at least allow for the system to quiet down and prevent any rogue scaler from saturating NATS traffic.

These could be done at the same time, or in one PR, and happy to advise for how to get this done! Help appreciated on knocking out the first bit