This issue is a subtask of #55

(It might be right that this should be reflected as an Envoy OSS issue, but going to discuss here because of the context)

Envoy OSS has a filesystem abstraction in order to manipulate the host's filesystem. The interfaces live here. A few months ago several folks from the OSS refactored the implementation of the filesystem abstraction in order to allow for platform specific implementations of the filesystem via bazel select statements like this.

The current implementations depend on APIs that don't exist or currently are not supported. Moreover, in Mobile architectures the Envoy thread would not have full access to the filesystem like it does when running on a machine in "server mode". Thus in order to be able to run tests that depend on the filesystem libraries, we need implementations that work against mobile architectures.

Note: I haven't looked into the watcher area of this problem space yet.

Where are these platform dependent libraries used in tests?

directory_lib
|_> //test/common/filesystem:directory_test
|_> //test/test_common:utility_lib

filesystem_lib
|_> //test/common/filesystem:filesystem_impl_test
|_> //test/test_common:utility_lib
|_> //test/test_common:file_system_for_test_lib
    |_> |_> //test/test_common:utility_lib

Note: it is funky that //test/test_common:utility_lib depends on both //test/test_common:file_system_for_test_lib and //test/test_common:file_system_lib. I need to look into that.

Options for a filesystem implementation that works against mobile architectures

1. Create usable filesystem implementations against each mobile architecture. This would allow us to depend on working implementations for tests, and potentially in production code. This might be easily done in a future version of Xcode that provides a sandboxed filesystem, and with the standardized std::filesystem library in C++17. I have not done research on this for Android.
2. Alternatively, we could create a fake filesystem implementation that builds an in memory filesystem against the API that Envoy has. This could very simply be implemented with a map of paths to simple FakeFile structs (that have a file type, a buffer, etc.). This option would be viable to run tests against both mobile architectures. However, it would obviously not be a usable model in production code.