executor: split interface Executor to a single package

[zz-jason]

What have you changed? (mandatory)

This is the first step to split the executor package. The executor package is too large, which contains a lot of source files with different functionality:

1. physical operator implementations
2. query adaptors
3. record set implementations

This pull request renames Executor to Operator and move it to a new package named operator. For further improvements, we can:

• make a new package named joins inside the operator package and move all the join implementations into it
• make a new package named readers inside the operator package and move all the reader implementations into it
• ...

What are the type of the changes (mandatory)?

• Improvement (non-breaking change which is an improvement to an existing feature)

How has this PR been tested (mandatory)?

• unit test
• explain test

[zz-jason]

@tiancaiamao PTAL

[zz-jason]

/run-all-tests

[jackysp]

The year should be 2018.

[winoros]

Will the structure become the following?

- executor:
    - base_operator:
    - join_operator:
    - agg_operator:
...

Or:

- executor:
    - operator:
        - join_operator:
        - agg_operator:
...

[winoros]

And the the structs whose name is end with Exec should be updated to Op?
Since the operator actually is execution operator, which is the same thing with executor.

[zz-jason]

@winoros Both ways are acceptable, I think we can just remove the Exec suffix?

[zimulala]

I think SeCtx or SCtx is better.

[tiancaiamao]

Is this really necessary to be in the Operator interface, as long as []*types.FieldType is provided ?

[tiancaiamao]

In the OO style, any Operator inherit a BaseOperator, so those methods are get from BaseOperator for free.
In Go, interface should be minimal so they can be composed more easy.
The more methods an interface contains, the less flexible it is.

[zz-jason]

we can do it in another PR, for these PRs, we just move code.

[tiancaiamao]

Is this really necessary to be in the Operator interface, as long as Schema() is provided ?

[tiancaiamao]

How about move the BaseOperator back to executor package, so those field need not to be exposed?
And we can better separate interface and implementation.

[zz-jason]

Agree this comment. As for other comments, I'll leave them for further improvement. These kind of PRs should only focus on the refactoring of code positions.

[zz-jason]

Oh, the whole plan is to move all the operator implementations into the new package "operator", during the development, we could have some operators inside the "operator" package, while other operators are outside that package. These fields are only exported temporarily. After all the operators are moved into that package, the exported field will be un-exported back.

[zz-jason]

This PR should be merged when release 2.1 is ready, for now I just leave it here for discussing.