chore: CON-1315 Switch proto conversions to *_id_try_from_option

[eichhorl]

Many places in the repository use the following structure to convert an optional ID protobuf type:

let id = *_id_try_from_protobuf(try_from_option_field(
    id_proto_option,
    field_name_str,
)?)?

This is confusing since it abuses the fact that TryFrom<T> is implemented for all T. Specifically, the call to try_from_option_field doesn't actually do any conversion, it simply extracts the value out of the option, or returns an error if no value exists.

This PR switches all of these occurences to their *_id_try_from_option equivalent, similar to what was done in 1292045 for the NodeId:

let id = *_id_try_from_option(
    id_proto_option,
    field_name_str,
)?

For UserId, such a function had to be introduced first. In the process of doing that I removed an unnecessary .unwrap() and return an error instead.

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

1. No behavior changes
2. No breaking changes
3. No data migration needed
4. No security review needed