prevent subject enumeration

In !564 (merged) we switched from using contact pseudonyms to subject IDs in subject URLs. This was part of a larger refactoring that got us from the confusing early days of castellum to the current structure: Subject management with subject IDs, recruitment/execution with participation IDs. This also is in line with the concept to use IDs within castellum and pseudonyms when communicating with the outside world.

Using IDs in URLs of course has security implications:

1. IDs are incrementing, so it is possible to derive a rough creation date from it
2. It is possible to enumerate objects, i.e. systematically try numbers to get all object (permissions still apply though)

Both were not considered an issue. Create dates are not secret and enumeration was seen as discouraged but not forbidden.

Recently this came back up and the argument was that while enumeration in this specific case may not be bad, preventing it is not that bad either.

So this is a possible implementation that prevents enumeration. It uses the query_pk_and_slug mechanism which was specifically designed for this. The idea is to use both an ID and slug in the URL. The ID is guaranteed to be unique, but can easily be guessed. The slug does not need to be unique, but is hard to guess. As both are required, the combination is both unique and hard to guess. Note that the ID is still included in the URL, so it still leaks a rough creation date.

The diff is large, but the conceptual change is not that big. It is a bit hard to validate that all subject views actually check the slug though, and this whole effort could be rendered futile by a single faulty view.

I cannot decide if I am for or against this change. It is a really small security improvement at the cost of a small amount of complexity.