Decide policy on stub implementations (syscalls, sockopts, flags, etc) about shadow HOT 2 OPEN

This is tricky, but I think I'm leaning toward some flavor of the opt-in options telling shadow to ignore missing features.

When Shadow was mainly used for running Tor simulations, it was reasonable to just silently ignore or warn-then-ignore in these types of stubs, because we did the debugging work to verify that Tor wasn't reliant in some important way on the unimplemented functionality. But now Shadow has become more suited to running general applications outside of the Tor world, and it is not really possible to check and verify that much larger set of applications. It comes down to guessing how important the underlying feature is to the functionality of an application, and the guesses are going to have wide error bars.

Technically, failing a syscall with EOPNOTSUPP when a feature is not supported is a valid thing for Shadow to do, even if an application was not written to handle that case (because, Linux would never dream of returning it). But if we do that, the nicest thing Shadow could do for users is to identify the problem and make it clear how to work around it.

1. log a warning message that clearly explains the feature Shadow thinks was being requested, that the feature is unimplemented, and an option that the user can use to tell Shadow to ignore and return success for that feature (e.g., "re-run the simulation with the option --ignore-keepalive if the application does not require this feature").
2. pre-add all of the missing stubs, i.e., enumerate as many missing features as possible and auto-generate all of the ignore options and warning messages so that users are not constantly having to submit PRs to add a stub for a feature their favorite app uses.

from shadow.

Allow all stubs as long as they also have a warning (typically warn_once_then_debug!()).

This seems reasonable to me. When I first started running shadow simulations with Snowflake, I went through the warnings to make a quick judgement call on whether the missing feature would impact the results. Though with how quickly Go has been changing, I'll admit I haven't gone over the missing features that don't cause errors to see if anything important is missing.

I don't necessarily think these quick judgement calls are as useful as doing some sort of validation experiments to give more confidence that the simulations are accurate enough for a given application to draw useful conclusions about it.

I just took a look at my shadow log for my most recent (minimal) Snowflake experiment and I see a lot of warnings:

$ grep "WARN" shadow.log | wc -l
68

Most of these are repeats and there are only 5 unique warnings for missing features.

Add an experimental config "stub" option which allows users to opt-into a list of stubs. This list would default to the stubs we already have and use, but new stubs would not be enabled by default.

This also sounds reasonable to me, and I see the value in app developers being made aware of new missing features and forced to make a conscious decision about whether or not the given feature is needed.

from shadow.