IMPALA-1442: Better fix for non-buffered SASL transports

The Thrift SASL implementation relies on the same transport being used
going in and out for the same peer socket (see
TSaslServerTransport::Factory::getTransport()). This means that the
transport's factory can't be used compositionally, as intended in the
last patch for this issue, as the wrapper factory has to be sure to hand
the SASL factory the same transport every time the same socket is passed
in, but we were creating a new buffered transport on each occasion.

This patch does something much simpler: the SASL factory is forced to
always create a buffered transport. This rather breaks compositionality,
but it was already broken by the factory's implementation.

Change-Id: Iec1a4337778e774ab8748e0412515abd07399c94
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5163
Reviewed-by: Matthew Jacobs <mj@cloudera.com>
Tested-by: jenkins
IMPALA-1134: Use copyBytes() to get value from o.a.h.io.Text

This affects java UDFs. Previously it was possible that the length of
the string returned from a java udf didn't match the actual data. Per the
Text.getBytes() documentation "... only data up to getLength() is
valid.". Impala just needs to use copyBytes() which is a convenience
function for this situation. The same should be done for BytesWritable.

Before:

Query: select length(echo('12345678901234567890'))
+-------------------------------------------+
| length(java.echo('12345678901234567890')) |
+-------------------------------------------+
| 22                                        |
+-------------------------------------------+

After:

Query: select length(echo('12345678901234567890'))
+-------------------------------------------------+
| length(functional.echo('12345678901234567890')) |
+-------------------------------------------------+
| 20                                              |
+-------------------------------------------------+

Change-Id: If9671278df8abf7529d3bc470c5f9d037ac3da1b
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4897
Reviewed-by: Casey Ching <casey@cloudera.com>
Tested-by: jenkins
IMPALA-1456: Hive UDFs with String args would crash impalad

The wrong buffer was being used.

Change-Id: I18bf9040eaeda871d1d0baee2e276749a3a38615
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5185
Reviewed-by: Casey Ching <casey@cloudera.com>
Tested-by: jenkins
Track unexpected remote reads

With this patch, we mark every scan range that is expected to be a
local read according to the file block metadata from the FE. After
finishing the scan range, we check if it was actually local and if
not, log a warning and add it to the runtime profile. This will help
us diagnose cases where the metadata is stale, causing remote reads.

Change-Id: I546da4ffb80d0af8ff8f5120e9639f9943f8b77d
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5115
Reviewed-by: Skye Wanderman-Milne <skye@cloudera.com>
Tested-by: Skye Wanderman-Milne <skye@cloudera.com>
Move fragment management out from ImpalaServer

ImpalaServer is still pretty big. One reason was that it was conflating
several separate responsibilities, including management of query
execution, management of fragment execution and responding directly to
Thrift RPCs.

This patch moves fragment execution into a separate FragmentMgr class,
and adds a (now-needed) proxy class to forward ImpalaInternalService
RPCs to either ImpalaServer or the FragmentMgr. Fragment management is
pretty self-contained (look at how small the resulting class had to be),
and so it was a good candidate to be broken out of ImpalaServer.

Change-Id: I24efb1a71a4225f9f85610565bf557a2e677e629
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/4854
Reviewed-by: Henry Robinson <henry@cloudera.com>
Tested-by: jenkins
Track expr memory allocations as part of parent node's usage

This change gets rid of RuntimeState::udf_mem_tracker_, and introduces
ExecNode::expr_mem_tracker to replace it. This way expr allocations
are still separate, but they fall under the correct exec node.

Change-Id: Iaf2cf610c2adf244ade94a9adb906cd68ad78838
Reviewed-on: http://gerrit.sjc.cloudera.com:8080/5000
Reviewed-by: Skye Wanderman-Milne <skye@cloudera.com>
Tested-by: jenkins