Transparent* database sharding

[icewind1991]

This implements (mostly) transparent database sharding with a custom query builder implementation that modifies the query as it's being built to run queries on sharded tables on the correct shards and split queries that join between sharded and non-sharded tables into separate parts.

The goal is that code using the database can (mostly) ignore sharding and "just work™". In practice it isn't quite transparent but most queries should be easy to make sharding compatible.

Partitioning

The first step is implemented in the PartitionedQueryBuilder, this query builder checks for all referenced in a query (from/update/join/etc) if they are configured to be sharded. And creates a separate "partition" for the sharded and non-sharded tables. Each partition has a "sub-query" that only references the tables from the partition. The various query parts (select/where/etc) are directed to the respective sub-query for the table they reference.

When executing, the various sub-queries are executed and the results are merged based on the configured join conditions.

See also the documentation of the PartitionedQueryBuilder class for some more info.

Sharding

Now that we have split of the part of the query that involves the sharded tables, the ShardedQueryBuilder no longer has to think about joins.

The ShardedQueryBuilder checks the configured sharding information for the tables it references and then looks in the query for the "shard key" (e.g. storage) or primary key (e.g. fileid) as the query is being built.

When executing, if the shard key is set in the query, then the query is only being ran on the shards for those shard keys.
If we only know the primary keys for the query, we first try to guess the shard that the primary key is likely to reside in. We do this by encoding the shard into the primary key when it's first being inserted. Since most rows are never moved to another shard this guess should have a fairly high success rate.
If we haven't found all the rows we are looking for from the likely shards, we loop over the other shards until we found all the rows for the primary keys being searched.

See also the documentation of the ShardedQueryBuilder class for some more info.

Query limitations

For all the automatic query inspection and manipulation mentioned above to work, various limitations to database queries are imposed. See the documentation of InvalidPartitionedQueryException and InvalidShardedQueryException for a list of limitations.

This PR adjusts various queries to be compatible with those limitations or adds alternate "sharding compatible" implementations of methods where having a query that is both compatible with these limitations and doesn't introduce a significant performance regression for non-sharded setups isn't possible.

Apps that touch the sharded tables will have to be tested for compatibility with sharding.

Configuration

Sharding can be configuration by setting the dbsharding config.php option. For each pre-defined "sharding config" (currently just "filecache"). A list of database configurations can be provided.

Each pre-definied "sharding config" (see \OC\DB\Connection::SHARD_PRESETS) defines the list of tables that will be sharded, the database field used for the shard key, and the primary key.

The configured database configurations are merged with the existing database configuration (overwriting) to get the final database configuration for each shard.

Changing the sharding configuration for installed instances is not supported atm.

For example:

"dbsharding" => 
	"filecache" => [
		"shards" => [
			[
				"port" => 5001,
			],
			[
				"port" => 5002,
			],
			[
				"port" => 5003,
			],
			[
				"port" => 5004,
			],
		]
	]
]

Will shard the filecache (and filecache_extended and files_metadata) over 4 database servers, running on port 5001 till 5004.

[artonge]

Rebased. Conflicts were mostly due to the updated cast rule of the new coding standard.

[sorbaugh]

/backport to stable30