Handle file streams differently

[aviramha]

Right now we do weird stuff with file streams, we should handle those similar to DirStreams - an object that is identified by usize (pointer) and points to a remote object (RemoteFile).
For example, on calling fclose we call fclose even if it's a stream managed by us, meaning this would most probably crash

This has not been tested yet, but we assume that running even simple flows with filestreams (e.g. by running mirrord on a node app) would break.

Functions to hook/fix

• ferror - right now returns last os error but not os error of the specific stream meaning we're probably returning something invalid.
• feof - need to hook
• clearerr - need to hook
• fileno - need to fix implementation
• fdopen - check mode matches existing open file
• fclose - need to fix

My proposed idea would be that most of the logic is layer-only, meaning we need some additional abstraction for fds similar to what libc provides:

#[derive(Default)]
pub(crate) struct FileStream {
    /// Raw Fd to use for operations (should be one managed by mirrord)
    pub(crate) fd: RawFd,
    /// Last error for `ferror` implementation
    pub(crate) last_error: c_int,
    /// is EOF for `feof` implementation
    pub(crate) is_eof: bool,
    /// for `flockfile`/`stuff_unlocked` implementation - skipped for now, leaving this
    /// in case we need to implement it later on.
    // pub(crate) lock: parking_lot::Mutex<()>,
}

[aviramha]

We needed to comment out flask http tests because those started failing with Fatal error: glibc detected an invalid stdio handle after most probably an update to werkzeug.

[meowjesty]

Looks like the culprit was __fsetlocking that would de-reference the * FILE, which we never filled with anything (as we were just passing it as a pointer address), you can see it in this implementation of it.

This all starts from how gethostname opens some network files using fopen and how __resolv_conf_load will end up trying to use __fsetlocking while reading /etc/resolv.conf.

[aviramha]

fixed in #1201