export mandates writing to local filesystem

[thz]

Quoting from the export docs:

  Start an export or import job.
  ## Params
  * `repo` - mandatory, the Ecto.Repo which contains the models to be exported
  * `models` - mandatory, list of modules which implement Ecto.Model
  * `options` - optional, Map whith the following options
    * `"filename"` - mandatory, string, the filename to export/import from
    * `"import"` - boolean, if true starts an import - default is false
    * `"formatter"` - atom, defines which module to use for string conversion - default is `Ecto.Export.Formatter.JSON`
  ## Result
  `{:ok, job_id}`

The mandatory option filename shows a painful limitation. ecto_export (as a low level library) must provide more flexible ways of accessing the data. Dumping data to stdout is the least ecto_export should support. That is todays "norm".
Compare to dump functionality of database systems, and even docker which allows piping whole images through a bare http-client based CLI. Compare to https://docs.docker.com/reference/api/docker_remote_api_v1.20/ REST endpoint GET /containers/(id)/export and still you can stream that on a UNIX system with the docker CLI.

[rixmann]

we had a meeting today and a lengthy discussion about ecto_export, regarding filename stdio etc. the following was decided:

the attribute filename is to be replaced by uri or export_uri
which is the endpoint to export to.

example values may be: scp:// file:// zmq-tcp://
only zmq-tcp (and maybe file which is the current behaviour) must be implemented at first.
for exporting to local filesystem use prefix: <configured_prefix>/<job_id>_filename

if the uri attribute is omitted, the data to export/import must be included with the request/response.