Limit internal termios API to pub(crate)

[Susurrus]

Fixes #1115

[Susurrus]

Needs a release note, but let's see how it goes through review and CI then I'll add one.

[asomers]

Just like integration tests, I don't think that doc tests are allowed to access private methods. That's why the tests are failing.

[Susurrus]

Just removed it entirely replacing it with a mem::zerod() call. Not a great solution, but considering the use case is just for documentation examples, I'm fine with it. Also added a CHANGELOG entry, so we should be good to go here.

Random thought: I just realized that we don't put the update libc version in the CHANGELOG even though it's part of our public API. We should probably add that as a Changed entry when we do releases.

[asomers]

Just removed it entirely replacing it with a mem::zerod() call. Not a great solution, but considering the use case is just for documentation examples, I'm fine with it. Also added a CHANGELOG entry, so we should be good to go here.

Random thought: I just realized that we don't put the update libc version in the CHANGELOG even though it's part of our public API. We should probably add that as a Changed entry when we do releases.

Is the libc version really part of the public API? A consuming crate can always pull in multiple versions of libc if it needs to.

[Susurrus]

Is the libc version really part of the public API? A consuming crate can always pull in multiple versions of libc if it needs to.

I'm not certain if we directly expose libc types in any of our functions or structs anymore, but we do re-export the entire library, so it's part of our API. So while downstream can use their own libc, their code may still break if libc changes underneath us and they use the version we re-export. I don't think this is a big deal for us, but I think because of it we should list the libc version for every nix release.