feat(wsl): Reuse metadata as Landscape installation_request_id

[CarlosNihelton]

Checklist:

• [x] I have signed the CLA: https://ubuntu.com/legal/contributors
• [x] I have included a comprehensive commit message using the guide below
• [x] I have added unit tests to cover the new behavior under tests/unittests/
  • Test files should map to source files i.e. a source file cloudinit/example.py should be tested by tests/unittests/test_example.py
  • Run unit tests with tox -e py3
• [x] I have kept the change small, avoiding unnecessary whitespace or non-functional changes.
• [x] I have added a reference to issues that this PR relates to in the PR message (Refs GH-1234, Fixes GH-1234)
• [x] I have updated the documentation with the changed behavior.
  • If the change doesn't change the user interface and is trivial, this step may be skipped.
  • Cloud-config documentation is generated from the jsonschema.
  • Generate docs with tox -e doc.

Proposed commit message

feat(wsl): Reuse metadata as Landscape installation_request_id

Recently the Landscape server started tracking the status of commands
delivered to clients that run on parent instances, notably the Ubuntu
Pro for WSL agent, by assigning request IDs which the pro agent refers
to when replying with the command completion status. For the case of
the Install command, which results in a new WSL instance being created
on the parent Windows machine and registered with Landscape, the
server also expects the same value to be part of the landscape-client
registration message. For that we need the `installation_request_id`
to be added to the client.conf file. We found that synergic to the concept
of `metadata.instance-id`, thus this refactoring in the WSL datasource aims
to allow:
- the pro agent to write a per-instance metadata file
- the WSL data source to use the `metadata.instance-id` as `installation_request_id`
   - if the landscape.client config exists
   - if doesn't contain that field.

Details were discussed in the specification document
"WS042 - Handle Landscape request_id in command Install via cloud-init"

Merge type

• [x] Squash merge using "Proposed Commit Message"
• [ ] Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

---

Fixes: UDENG-6773

[CarlosNihelton]

@blackboxsw , pinging you since you have all the context of the spec.

[github-actions[bot]]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging TheRealFalcon, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag TheRealFalcon to reopen it.)

[github-actions[bot]]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging TheRealFalcon, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag TheRealFalcon to reopen it.)

[blackboxsw]

I think there is an inconsistency in this PR as far as the .ubuntupro/.cloud-init subdirectory where ds-identify and docs expect Pro/Landscape user-data versus what the python datasource is checking now.