Add support for brotli compression

[moose-kazan]

Hi!

This PR add support for brotli-compressed files.

[zyv]

Unfortunately, --time-style is not POSIX, and I don't have it on macOS and BSD. Can't you use Perl like here?

perl -MPOSIX -le '...'

mc/src/vfs/extfs/helpers/dpkg+.in

Lines 100 to 109 in 2bde8f7

	sub ls {
	my ($file,$path,$mode) = @_;
	if (-f $file) {
	my @stat = stat(_);
	# mode, nlink, uid, gid, size, mtime, filename
	printf "%s %d %d %d %d %s %s\n", $mode || ft($file).fm($stat[2] & 07777),
	$stat[3], $stat[4], $stat[5], $stat[7], bt($stat[9]), $path;
	}
	}

Then you also won't need awk.

[moose-kazan]

Good idea!

I was rewrite code in Perl (see new commit).

offtop: for future cases: which language preferred for similar tasks? It seems to me that it bash. But if you recommend Perl - i will use it with pleasure. I well know and much like Perl.

[zyv]

This is a good question, but I don't have an equally good answer.

Historically, extfs modules were written in any language that the contributors saw fit and the maintainers would accept. The majority were written in shell, but some "complicated" modules were written in Perl or Python.

My long-term vision would be to provide an ECMAScript execution engine and have them re-written in ECMAScript. It will speed up the modules dramatically, the language is better than the mix of shell with other POSIX tools, we could have sane tests for the modules, there is an ecosystem of development tools, etc. If and when this will happen, I don't know.

For now, my strategy was to accept modules that work on POSIX systems if they are written "the old way", and Python/Perl modules if they are not expected to be used on machines like routers featuring Busybox and lacking most common interpreters.

In this case, I think Perl is okay, because it's unlikely that anyone would want to use Brotli VFS in this context. Also, I don't know Perl and I don't like it, but it seems to me that it looks much cleaner than the shell attempt now.

[zyv]

This is a good question, but I don't have an equally good answer.

Historically, extfs modules were written in any language that the contributors saw fit and the maintainers would accept. The majority were written in shell, but some "complicated" modules were written in Perl or Python.

My long-term vision would be to provide an ECMAScript execution engine and have them re-written in ECMAScript. It will speed up the modules dramatically, the language is better than the mix of shell with other POSIX tools, we could have sane tests for the modules, there is an ecosystem of development tools, etc. If and when this will happen, I don't know.

For now, my strategy was to accept modules that work on POSIX systems if they are written "the old way", and Python/Perl modules if they are not expected to be used on machines like routers featuring Busybox and lacking most common interpreters.

In this case, I think Perl is okay, because it's unlikely that anyone would want to use Brotli VFS in this context. Also, I don't know Perl and I don't like it, but it seems to me that it looks much cleaner than the shell attempt now.