Namespace for sbus scale rules

[Larocceau]

This PR closes #1188

The changes in this PR are as follows:

• Adds the field namespace to the ServiceBusScaleRule, which is used to associate the scale rule to the right sbus

I have read the contributing guidelines and have completed the following:

• Tested my code end-to-end against a live Azure subscription.
• Updated the documentation in the docs folder for the affected changes.
• Written unit tests against the modified code that I have made.
• Updated the release notes with a new entry for this PR.
• Checked the coding standards outlined in the contributions guide and ensured my code adheres to them.

If I haven't completed any of the tasks above, I include the reasons why here:

• Instead of testing on a existing deployment, I compared a ARM template of a successful implementation of this feature using a custom scale rule, with one using this feature. There was no significant difference in the two templates.

Below is a minimal example configuration that includes the new features, which can be used to deploy to Azure:

containerApp {
      ....
      add_servicebus_scale_rule "sb-keda-scale" {
          QueueName = "wishrequests"
          MessageCount = 5
          SecretRef = "servicebusconnectionkey"
          Namespace = "servicebus"
      }
}

[Larocceau]

@mattgallagher92 this is ready for review

[mattgallagher92]

Is this field optional? If so, this change will break any existing clients, so we should probably make the new field optional too. If it's mandatory then there can't be any existing clients so we don't have to worry about that, in which case this change is fine (but I've added some comments about some things to improve).

[mattgallagher92]

Should one of the tests check that the value is set correctly?

[mattgallagher92]

Do the docs need updating too?

[ninjarobot]

@Larocceau sorry for the delay, are there any updates on the docs and testing so this can get completed?

Please @ me if you need more information.

[Larocceau]

Hi @ninjarobot! Sorry for the delay; things been a bit messy for us, and I've left CIT (as has most other dev staff). I did not get around this, but would be happy to wrap this up later.