Storing the user assigned managed identity in the scaleset table

[chkeita]

Summary of the Pull Request

Closes #249

PR Checklist

• Applies to work item: Throttling issue with calls to user assigned managed identities #249
• CLA signed. If not, go over here and sign the CLI.
• Tests added/passed
• Requires documentation to be updated
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Info on Pull Request

What does this include?

Validation Steps Performed

How does someone test & validate?

[bmc-msft]

How does this handle pre-existing scalesets during the upgrade case?

[chkeita]

Existing scalesets are handled in the is_authorized function in agent_authorization.py.

• if the scaleset had a system assigned managed identity it would have been assigned to client_object_id
• if the scaleset used a user assigned managed identity before this change we fall back to the existing behavior of querying the azure.

Unfortunately we cannot update the object id of the scaleset because the token does not contain the scaleset id.

[bmc-msft]

If a user starts the creation of a scaleset and another user starts an upgrade shortly afterwards, this could leave that newly created scaleset in a bad place such that it does not have the client_object_id

[chkeita]

I Updated the logic to make sure we only set the node to running if we are able to set the object_client_id. your scenario will result in a failed node creation.