Remove some linux-specific musl headers

[sbc100]

We don't implement any of the functions declared in these headers, so
there is not real use for them, and I think it can be misleading to allow
them to be included at compile time.

See already did this for sendfile.h: #14248

See #17638

[kripken]

Changing the arch file for emscripten sounds good, but the other changes are in generic code, which means they'll show up in diffs to upstream musl and make upgrading less simple, won't they?

[sbc100]

Changing the arch file for emscripten sounds good, but the other changes are in generic code, which means they'll show up in diffs to upstream musl and make upgrading less simple, won't they?

All of the other changes to upstream header are simply removing entire files. I decided it was cleaner just to remove them completely. We could create a list of files to exclude in system/lib/update_musl.py in perhaps, but I'm not sure its necessary right now. Its easy to avoid re-adding them up update I think.

[sbc100]

Changing the arch file for emscripten sounds good, but the other changes are in generic code, which means they'll show up in diffs to upstream musl and make upgrading less simple, won't they?

All of the other changes to upstream header are simply removing entire files. I decided it was cleaner just to remove them completely. We could create a list of files to exclude in system/lib/update_musl.py in perhaps, but I'm not sure its necessary right now. Its easy to avoid re-adding them up update I think.

The only other change in this PR is a change to test file..

[sbc100]

Add a ChangeLog entry just in case.

[kripken]

It's easy to avoid re-adding them, but it is another thing to need to remember to do. Musl adding a new file might be confusing here, also - both would look like a file that only exists in upstream.

I'm not strongly opposed, but this seems like fairly low benefit, and there is some risk of breakage (like happened in our tests, it seems) so I'm not sure this is worth it? How big do you see the benefit as?

[sbc100]

It's easy to avoid re-adding them, but it is another thing to need to remember to do. Musl adding a new file might be confusing here, also - both would look like a file that only exists in upstream.

I'm not strongly opposed, but this seems like fairly low benefit, and there is some risk of breakage (like happened in our tests, it seems) so I'm not sure this is worth it? How big do you see the benefit as?

I updated the update_musl.py script to match these changes. I think it is a lot cleaner/better not to ship headers for random stuff we don't support.

When I run update_musl.py against the emscripten branch of musl it now does not create any new files.

Also, note that we had already pruned at least one file prior to this change "sendfile.h". See #16234

[sbc100]

And #14248

[kripken]

Ok, fair enough. I don't feel strongly and those are reasonable reasons.