Updated Alpine/Samba plus WSDD

[M0les]

This was borne out of a desire to use the dperson/samba Docker image with "modern" Windows clients (10/11).
This requires both an updated Samba version and also the ability to do Windows Service Discovery (WSD). While we wait to see if Samba integrates WSD, the wsdd script will fill the gap. Fortunately all this is available as Alpine packages, so I make a fork to pin to a specific known-working combination of all software versions (for deterministic builds).

Effective changes from the base version

• wsdd daemon added to the installed package list
• OS and all installed packages pinned to specific versions (plus no package-update in the build) - this is all to ensure determinism.
• WSDD uses serving multicast traffic, which requires access to the host network (--net host)
• Added a new -d flag to either disable wsdd (if given an optarg of false), or to pass any optional parameters to the wsdd daemon otherwise.
• Runs a chmod +x on the samba.sh script in the container to be able to start it from tini.
• Runs wsdd in samba.sh just before smbd
• Removed the -S parameter to smbd, as this was deprecated in Samba v4.15 (Was: "log to stdout")

Things to note:

• The wsdd service requires serving multicast data. As best I can determine, Linux containers can only work with multicast if they are directly connected to the host network (--net host). While there's lots of mentions of opening ports (-p nn:nn) and the actual smbd service will still work that way, the service won't be discoverable by Windows clients without the wsdd service working properly (i.e. the serving host won't show-up automatically in the File Explorer's "Network" view). I'm far from being a container networking expert and I only have an IPV4 local network to test with. So it's entirely possible someone might be able to figure-out a more restrictive way to map ports for multicast (but it isn't going to be me).
• The initial cut of this was developed through an Anthropic/Claude query. The results were only slightly broken/delusional (one missed breaking-change in smbd and one hallucinated wsdd parameter). However the result was also a reasonably large diff as it added a bunch of minor coding improvements, style changes and in-line documentation. I spent considerable effort "minimising" the diff and converting it to something that seemed to fit the original repo's coding style better. I believe I've achieved the bare minimum diff now. Ultimately I think there's only one or two lines left that I would attribute to the AI's original output (some variable and output handling). I don't really consider this "vibe coding" (because I understand everything it did and trimmed-out or reshaped it anyway), but you may have your own ideas about it, so you have all the information you need to make your own decision.
• Although I've updated the Dockerfile's "maintainer" information to implicate myself instead of David Personette, I don't have any plans to support/maintain this in the future. I might roll-out new builds with updated OS or repository packages, but I don't plan on making any other changes to this repo's code. My ideal is anything "good" in here could be merged into the base repository (however, I don't have any expectation or entitlement to that).
• Although the original repo is pretty "Docker-specific", I worked on this using only Podman (on a Fedora 44 host). I can't see this causing issues for Docker users, but I've done no testing to prove this.
• As mentioned in the changes section, this build now pins the versions of the Alpine image as well as all the installed packages (as well as removing the package update in the build). The intention to to make a deterministic container image. While this ensures compatibility between all the software components in the image, it increases the risk of incompatibility with newer clients and also the risk of latent security issues. I'd expect that if I ever produce newer releases of this repo and images built from it, I'd be updating some of these pinned versions to later ones (and not much else).