Allow exporting specific columns

[DmitryAstafyev]

Introduce changes, which gives user a way to export data into text file only with specific (selected) columns.

Added

• API on rustcore
• API on electron side and on client side
• New dialog on client

[AmmarAbouZor]

I think those fields could be grouped in an optional struct, since they can have values always together. (There is no path in code for a case where a splitter is provided without a delimiter and the columns is used only on the case where both splitter and delimiter are provided)

Maybe a struct like ColumnsModificationSettings that have them all which can be wrapped inside an Option as a whole would be clearer. For sure this change can be carried to all the other modified export function and structs

[DmitryAstafyev]

Yes I also thought about it. I've refused from object because of node-bindgen. Such an object would also go there, and it will require using of something like serde_json, which I'm trying to avoid considering possibly switching to protobuf way. Because if we will move to protobuf, I think we will also get rid of serde_json at all. Well that's why I left it for now "flat".

[DmitryAstafyev]

and in the scope of "move to protobuf" we will group arguments of all public API into messages to switch it also to proto and make more structured.

[AmmarAbouZor]

I think we can consider the option to have the new struct on the levels where node-bindgen doesn't have access.

I think this can start before the function state.export_sesssion(...) on line 348 (if it's not a part of the bindgen), at that point we can map those three fields to one struct and use it in the rest of Rust code.
Then it would be easier to replace the three fields with the struct once "move to protobuf" is done because we would already have the struct and we just need to export it and remove the mapping in one place.

[DmitryAstafyev]

This enum element (and others enums too) as itself is already a struct of options of export.

Export {
        /// The output path where the exported data will be written.
        out_path: PathBuf,
        /// The ranges of data to be exported, each defined as an inclusive range.
        ranges: Vec<std::ops::RangeInclusive<u64>>,
        /// The indices of the columns to include in the export.
        columns: Vec<usize>,
        /// An optional string used as the record separator in session file to split log message to columns. Defaults can be applied if `None`.
        spliter: Option<String>,
        /// An optional string used as the field delimiter within each record in output file. Defaults can be applied if `None`.
        delimiter: Option<String>,
    }

Introducing here an additional level of nesting looks to me excessive, even if some of the fields are used in pairs.

But I agree we need grouping on level of public API:

    pub fn export(
        &self,
        operation_id: Uuid,
        out_path: PathBuf,
        ranges: Vec<RangeInclusive<u64>>,
        columns: Vec<usize>,
        spliter: Option<String>,
        delimiter: Option<String>,
    ) -> Result<(), ComputationError> {

That's obviously not good to have so many arguments. But this is a common problem and it's out of the scope of current changes. In general, we should introduce a common API interface to come to some uniformity for all public methods. Let's say with only 2 arguments always: ident, options. And also it's related again to protobuf integration because it's much closer to this subject.