Add support of field boost in common terms query

[spigene]

As for now, ES ignores field level boost factors specified in mapping during computation of documents' score for common terms query.
This places certain restrictions on the client of ES.
E.g., the client has to specify different boost factors manually if he want to have distinct scores for the same term retrieved from two fields.
This quickly becomes unmanageable if the client has no direct control over search fields or if this number grows fast.
The absence of the described functionally looks especially weird comparing to the way how regular terms query works (it does honor field level boosts, see below).

Sample setup:

1. Create index and mapping.

curl -XPUT 'http://localhost:9200/messages/'

curl -XPUT 'http://localhost:9200/messages/message/_mapping' -d '
{
    "message" : {
        "properties" : {
            "message" : {"type" : "string", "store" : true },
            "comment" : {"type" : "string", "store" : true , "boost" : 5.0 }
        }
    }
}'

2. Create sample docs

curl -XPUT 'http://localhost:9200/messages/message/1' -d '{
    "user" : "user1",
    "message" : "test message",
    "comment" : "whatever"
}'

curl -XPUT 'http://localhost:9200/messages/message/2' -d '{
    "user" : "user2",
    "message" : "hello world",
    "comment" : "test comment"
}'

3. Wait for ES to be synced

curl -XPOST 'http://localhost:9200/messages/_refresh' 

4. Search in default catch-all field using term query

curl -XPOST 'http://localhost:9200/messages/_search' -d '{ "query" : { "query_string" : { "query" : "test" } } , "explain" : true }' | python -mjson.tool

5. Search in default catch-all field using common terms query

curl -XPOST 'http://localhost:9200/messages/_search' -d '{ "query" : { "common" : { "_all" : { "query" : "test" } } } , "explain" : true }' | python -mjson.tool

The first query (step 4) works as expected -- document with id equal to 2 has higher score.
The result of second query (step 5) is opposite.

[s1monw]

ok I see the problem here I guess I have to fix that in lucene as well.... thanks for reporting this