sfsturbo: Share create silently drops metadata (breaks expand_type, blocks HPC hpc_bw)

[shhovhan]

Summary

When creating an SFS Turbo file system, the metadata block (containing expand_type, crypt_key_id, and — for HPC — hpc_bw) is silently dropped before the request is sent. As a result:

• The existing enhanced file system feature (expand_type: bandwidth) does not work — users get a standard file system with no error.
• HPC file systems cannot be created at all, because hpc_bw has no way to reach the API.

Root cause

otcextensions/sdk/sfsturbo/v1/share.py — the Share resource declares expand_type as a top-level resource.Body field (used for read/list responses) but has no metadata body field.

openstacksdk's Resource only serializes attributes that are declared as resource.Body(...). Any unrecognized attribute is discarded unless _allow_unknown_attrs_in_body or _store_unknown_attrs_as_properties is enabled — both default to False and Share does not override them. So a metadata={...} passed to create_share() never enters the request body.

API reference

Creating a File System — SFS Turbo API Reference, Table 5 (Metadata):

• expand_type — enum: bandwidth (Standard-/Performance-Enhanced) or hpc (HPC flavors).
• hpc_bw — mandatory when creating an HPC file system. Values: 20M, 40M, 125M, 250M, 500M, 1000M.
• crypt_key_id — KMS key for encrypted file systems.

Note: share_type stays STANDARD / PERFORMANCE even for HPC; the HPC flavor is selected entirely via metadata.

Proposed fix

• Add a writable metadata body field to the Share resource so the nested object is serialized on create (carrying expand_type, hpc_bw, crypt_key_id).
• Keep top-level expand_type for read/list responses.
• Update create_share example and add a unit test asserting metadata (incl. hpc_bw) is serialized into the create body.

Impact

• Fixes the currently broken expand_type: bandwidth (enhanced) behaviour.
• Unblocks HPC support in the Ansible collection (opentelekomcloud/ansible-collection-cloud), which depends on this.