feat(lvol): create volumes with fixed (thick) provisioning by default

[schmidt-scaled]

What

Create volumes with fixed (thick) provisioning instead of thin.

bdev_lvol_create was always issued with thin_provision=True, so a volume's clusters were allocated lazily on first write. This changes the RPC to allocate the blob's clusters up front at create time, committing the full logical size immediately.

Change

Both RPC wrappers in simplyblock_core/rpc_client.py, together (they must agree — a replica/recreate registers the same blob its primary created):

• create_lvol(..., thin_provision=False) — the bdev_lvol_create RPC
• bdev_lvol_register(..., thin_provision=False) — replica / recreate registration

thin_provision is a parameter (default False), not a hard flip, so thin can still be requested explicitly per call.

Tests

tests/unit/test_lvol_fixed_provisioning.py (6) — create + register default to fixed, both can opt back into thin, defaults agree, no hardcoded True remains. Full unit suite 1873 passed / 7 skipped; ruff + mypy clean.

For review — please weigh in

This is a blanket behaviour change with real implications; flagging them explicitly rather than assuming:

1. Capacity. Thick reserves the full logical size at create. A pool/cluster that was comfortably oversubscribed under thin can now hit provisioning limits far sooner. Do the pool/cluster admission checks (set_pool / prov-cap) already account for this, or do they assume thin?
2. Scope. This flips every create_lvol caller: base volume create, migration targets (migration_controller, tasks_runner_lvol_migration), and any recreate. Is thick intended for all of those, or only operator-created base volumes? If the latter, the flag should be plumbed from the create API rather than defaulted at the RPC.
3. Clones / snapshots. These use separate RPCs (bdev_lvol_clone / bdev_lvol_snapshot) and are not touched here — a clone stays thin. Is that the intended split, or should clones be thick too?
4. Existing volumes. Only affects newly created blobs; existing thin volumes are unchanged (and bdev_lvol_register of an existing blob replays its stored provisioning via blobid).

Happy to narrow the scope (e.g. plumb a --thick flag from the CLI/API through to create_lvol) if a blanket default isn't what's wanted.