Improve/fix named threads

[BlackMark29A]

This PR addresses two issues regarding named threads:

• The main thread was named cy-main, however, user code running in the main thread could spawn new threads, which would then inherit the same name, leading to more than one cy-main thread. This behavior is probably more confusing than useful and this PR thus no longer gives the main thread a special name.
• On macOS the pthread_setname_np function used to set the name of threads has a different signature than on linux. This in and of itself is not an issue, however, the macOS version can only set the name of the calling thread, which is incompatible with the way celerity currently implements named threads. Therefore this PR adds a feature flag CELERITY_FEATURE_NAMED_THREADS to disable the feature entirely on macOS.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[PeterTh]

I feel like it would make more sense to use the #if CELERITY_FEATURE_NAMED_THREADS to define or stub out set_thread_name, rather than doing it at every call site. This keeps the general code (where the call sites are) cleaner.

[BlackMark29A]

I wanted to not use a feature flag at all and so my first implementation had a similar idea of having a third stub implementation that would just print a warning that the feature was unsupported, however that obviously didn't work for the unit tests and so I added the feature flag.

I like the idea of keeping the call-sites unchanged, so I'll move the feature flag inside the implementation.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[fknorr]

Feature detection macros were originally intended for public APIs, like celerity::local_accessor. This would be a new use for purely internal considerations.

We have a workaround for a similar problem when querying the affinity mask, which apple does not implement the way we want either. There, we exclude the translation unit affinity.unix.cc and use a #ifdef __APPLE__ at the call site.

Without clearly preferring one over the other, these two cases should be handled in a similar manner.

[BlackMark29A]

I did not know feature detection macros were intended to be public, in that case if we decide to keep them for this use case we should clearly mark them as being INTERNAL or PRIVATE or DETAIL.

As @PeterTh already pointed out it is cleaner to keep the call-sites unchanged, which I agree with. As for using __APPLE__ vs a feature detection macro, I would say it depends. Inside named_threads.unix.cc I would actually prefer __APPLE__, as this relates to platform specific code, however for disabling the unit test I think using CELERITY_(INTERNAL)_FEATURE_NAMED_THREADS is better, because the unit test doesn't use any platform specific code, and so disabling it based on feature availability makes more sense to me, especially since the decision whether the feature is available or not is actually made by the build system, and not by the unit test implementation.

Thoughts?

[fknorr]

There is precedence for CELERITY_DETAIL_ in macros.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[fknorr]

LGTM!

[psalz]

One minor remark, otherwise LGTM! Please squash before merging.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"