Optimize the parquet RecordReader implementation when: A. filterpredicate is pushed down , B. filterpredicate is pushed down on a flat schema

The RecordReader implementation currently will read all the columns before applying the filter predicate and deciding whether to keep the row or discard it.
We can have a RecordReader which will only assemble the columns on which filters are applied (which are usually a few), then apply the filter and decide whether to keep the row or not , and then goes on to assemble the remaining columns or skip the remaining columns accordingly.

Also for applications like spark sql , the schema usually applied is a flat one with no repeating or nested columns. In such cases, its better to have a light-weight, faster RecordReader.

The performance improvement by this change is seen to be significant , and is better in case smaller number of rows are returned by filtering (which is usually the case) and there are many number of columns

**Reporter**: [Yash Datta](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=saucam) / @saucam

_{**Note**: *This issue was originally created as [PARQUET-128](https://issues.apache.org/jira/browse/PARQUET-128). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*}

Bắt đầu bằng cách xác định phần triển khai của RecordReader và cách xử lý filter-predicate hiện có; issue không nêu tên các tệp hoặc bài kiểm thử cụ thể. So sánh hành vi hiện tại với việc lắp ráp các cột đã lọc theo yêu cầu và lightweight path cho các schema phẳng, đồng thời xác định việc hoàn thành thông qua các phép đo hiệu năng cho thấy mức cải thiện dự kiến.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.