wdavis/feat/add iotest mechanism to beegfs-go to drive client io

[Willard84]

What does this PR do / why do we need it?

Adds beegfs iotest, a tool for driving IO workloads built into beegfs.
It has 3 components:

1. verifyio, a Go library to drive POSIX IO.
2. Client-side IO testing tools using the verifyio library. These tools
   are relatively simple and more about demonstrating functionality than being final products.
3. A framework to drive multi-node IO using those client-side tools.

The goal of this is to drive IO in a customer-like manner: requests flow
from the client module → network → storage.

The verifyio library is intended to support both benchmark mode (where
we just write the data as quickly as possible) and a verification mode,
where we place xattrs with checksums alongside the file to allow for data
verification. The written data also includes checksums to allow the
detection of bit rot.

For the tooling, there are currently two modes:

• Standalone probes (smoke, verify, dump): quick, single-node
  checks: write+verify a sanity check in one shot, verify existing data
  files, or dump a file's block headers for inspection.

• Framework-managed multi-node workloads (bench, soak, inval):
  SSH fan-out across nodes, shared-path status files, and a
  start/status/stop/cleanup lifecycle. bench measures bandwidth,
  soak is a long-running write/re-write stress test that surfaces
  silent corruption and torn writes under sustained load, and inval
  measures cross-node metadata cache-invalidation latency.

Related Issue(s)

This is the beginning of work toward #324

Where should the reviewer(s) start reviewing this?

Begin with the verifyio library (the first commit). This covers the
block format, xattr store, locking, and the verification code.

Then the various consumers of the library, and finally the interface
into the beegfs CLI.

What are the next steps after this PR?

There are a lot of improvements planned for all of these features long
term. This is intended to be the initial commit for a lot of additional
work — a starting point, not a finishing point.

The next steps planned for the verifyio library include: mmap support,
various directory stress/verification mechanisms,
non-fcntl inter-node locking, and more programs for cache-coherence testing.
Then, adding consumer test programs for those features.

Checklist before merging:

• Documentation:
  • Does developer documentation (code comments, readme, etc.) need
    to be added or updated? — documentation for the CLI is in
    ctl/internal/cmd/iotest/DESIGN.md, and for the verifyio library
    in verifyio/README.md.
  • Does the user documentation need to be expanded or updated for
    this change?
• Testing:
  • Does this functionality require changing or adding new unit
    tests? — this includes unit tests for the verifyio library; no
    additional unit tests required for this PR.
  • Does this functionality require changing or adding new
    integration tests? — no.
• Git Hygiene:
  • Do commits adhere to Conventional Commits?
  • Is the commit history squashed down reasonably?