mem: Don't use hasSharers in the snoopFilter for memory responses

When the snoopFilter receives a response, it updates its state using
the hasSharers flag (indicates whether there are more than one copies
of the block in the caches above). The hasSharers flag of the packet
was previously populated when the request was traversing and snooping
the caches looking for the block.
1) When the response is coming from the memory-side port, its order
with respect to other responses is not necessarily preserved (e.g., a
request that arrived second to the xbar can get its response first). As
a result the snoopFilter might process responses out of order updating
its residency information using the non valid hasSharers flag which was
populated much earlier.
2) When the response is from an on-chip, the MSHRs preserve a well
defined order and the hasSharers flag should contain valid
information.

This patch changes the snoopFilter by avoiding the hasSharers flag
when the response is from the memory-side port.

Change-Id: Ib2d22a5b7bf3eccac64445127d2ea20ee74bb25b
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>

src/mem/snoop_filter.cc

@@ -358,11 +358,7 @@ SnoopFilter::updateResponse(const Packet* cpkt, const SlavePort& slave_port)
     panic_if(!(sf_item.requested & slave_mask), "SF value %x.%x missing "\
              "request bit\n", sf_item.requested, sf_item.holder);
 
-    // Update the residency of the cache line. If the response has no
-    // sharers we know that the line has been invalidated in all
-    // branches that are not where we are responding to.
-     if (!cpkt->hasSharers())
-        sf_item.holder = 0;
+    // Update the residency of the cache line.
     sf_item.holder |=  slave_mask;
     sf_item.requested &= ~slave_mask;
     assert(sf_item.holder | sf_item.requested);