ACCUMULO-2896 Make PATH_PROPERTY_ENV_VARS final
Merge branch '1.6.1-SNAPSHOT'

Conflicts:
	core/src/main/java/org/apache/accumulo/core/Constants.java
ACCUMULO-2927 More targeted git ignores (per-module)
Merge branch '1.6.1-SNAPSHOT'
ACCUMULO-2927 Add .gitignore for mapreduce and shell modules
ACCUMULO-2928 Add equals, hashCode and toString to batchwriterconfig.

Also includes some formatting changes. Includes some basic tests to make sure
hashCode and equals are functioning.
Merge branch '1.5.2-SNAPSHOT' into 1.6.1-SNAPSHOT

Conflicts:
	core/src/main/java/org/apache/accumulo/core/client/BatchWriterConfig.java
Merge branch '1.6.1-SNAPSHOT'

Conflicts:
	core/src/main/java/org/apache/accumulo/core/client/BatchWriterConfig.java
ACCUMULO-2925 Don't recalculate the name multiple times.
ACCUMULO-2925 Create regular Mutations from ServerMutations when applying replication data on a peer

Mutations do not store unserialized ColumnUpdates, but only generate them
on demand via the getter. This is intended to create an efficient implementation
(both performance and size) while preseving immutability.

Server-assigned timestamps work around this immutability by wrapping normal
Mutations in a ServerMutation and ColumnUpdates with ServerColumnUpdates. By doing
this, ServerMutations can "fake" the timestamp on ColumnUpdates that otherwise
do not have a timestamp set.

In the context of replication, this is still a problem as all Mutations that are
sent to a peer are ServerMutations (as we read them from a WAL). These Mutations are
deserialized and passed into a BatchWriter to apply to the local instance; however, the
BatchWriter is ignorant of ServerMutations and the special timestamp handling.

When the BatchWriter makes a "copy" of the Mutation (see ACCUMULO-2915), despite this
being a shallow copy, the server-assigned timestamp is lost by creating a regular
Mutation from what was a ServerMutation. Even if this were possible, the TMutation
class, which the BatchWriter eventually uses to send to the Mutations to a TabletServer,
is also ignorant of the ServerMutation timestamp without modification of the serialization
and TMutation class.

As such, the only option left is to, when encountering ServerMutations in the BatchWriterReplicationReplayer
code, we *must* recreate new Mutations, applying the possibly present server-timestamp to
each new Mutation we create to ensure that the timestamp is correctly propagated to this peer.
ACCUMULO-2925 Need to preserve replicationSource on the Mutation

The replicationSource on the Mutation is the information which prevents cycles
in the replication graph from infinitely replicating information. Each replicationSource
on a Mutation is the `replication.name` for a system from which that Mutation came.

We can later use this set to determine if we need to replicate this Mutation
to a given peer by observing if the `replication.name` of our peer already
exists in the replicationSources.
ACCUMULO-2930: Update classes still using AccumuloClassLoader.getClassLoader() to use AccumuloVFSClassLoader
ACCUMULO-2925 Remove inadvertently deleted log message
ACCUMULO-2925 Add test to ensure that replicationSource(s) are preserved before replay
ACCUMULO-2925 Add warning about server-assigned timestamps with replication

Leave a note about updates to equal keys that have different updates that are
assigned the same timestamp by the server.
ACCUMULO-2926 Fix the multiple slf4j bindings that ACCUMULO-2808 introduced
Merge branch '1.6.1-SNAPSHOT'
ACCUMULO-2935 Add a timeout to a test that otherwise hung indefinitely
Merge branch '1.6.1-SNAPSHOT'
ACCUMULO-2937 Mark a todo