testsuite: use libafpclient transport interface

[rdmark]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔥 Spectest (AFP 3.4) - Flamegraph (AFP_ASSERT active)

Commit: c4216e892ab876ffa0f363063e038a01f04aa660
Profiling: On-CPU sampling @ 2000 Hz, DWARF call-graph, x86_64
Build: debugoptimized (-O2 -g -fno-omit-frame-pointer)
Total Runtime: 67s, Netatalk Code-time: 3.9%,
Stacks: 3354, SVG size: 1.8M

🔥 Open interactive Flamegraph (SVG)

📥 Download from artifacts →

🔝 Top 10 leaf functions

Function	Samples
do_syscall_64	369500000
_raw_spin_unlock_irqrestore	250000000
finish_task_switch.isra.0	121500000
__cp_end	86000000
srso_alias_safe_ret	68500000
find_get_block_common	45000000
__syscall_cp_c	29500000
kmem_cache_alloc_noprof	23000000
file_close_fd	22000000
kmem_cache_free	21500000

[rdmark]

@andylemin putting this up for transparency -- it's an early stage experiment, not ready for review! but it mostly works and demonstrates an AFP test client using afpfs-ng / netatalk-client libafpclient instead of the simplistic testsuite client.

note that the CI jobs do not use the new transport: you need to have libafpclient.so and headers installed, and without them falls back to the legacy client. I'm actively working towards a first netatalk-client release tarball before setting this up in the pipeline.

as you're doing your own overhaul of the testsuite right now, I wanted to give you a heads-up that a number of tests needed rework, because of various reasons, such as accessing the raw DSI responses in ways that isn't valid when using the libafpclient. there are still a large number of newly skipped tests that need further investigation.

a strategic decision that we should make: go all in on libafpclient and purge the legacy test client, or keep the legacy client as a fallback and for low level DSI tests. the former is cleaner and more maintainable, while the latter enables a different class of tests.

[rdmark]

@NJRoadfan I've tested that this enables the testsuite to run with DHX2 or SRP auth!

[andylemin]

@rdmark Nice, thanks for the example.
I do not see any conflict here with the lock bugs + tests & the general AFP Spec coverage tests I'm working on. So I will carry on as planned.
Once netatalk_client is more polished we can swap the auth layer as required. Many of the Spectests will need to continue using the more direct access patterns to perform more complex test cases, but the simple ones can easily be migrated.