SetupInterfaceCount is currently useless

[permcody]

Description of the enhancement or error report

SetupInterfaceCount was designed to verify that we don't get double calls to constructors or other callbacks. It was recently restricted to run in serial so it's much less useful then it was before #9423. I believe we could still make a robust object if we carefully controlled the partitioner and dimensionality of the mesh (i.e. 1D or at at least a one direction mesh).

Rationale for the enhancement or information for reproducing the error

Right now this object doesn't accomplish very much since it can only test serial, non-threaded cases. It should be expanded to run in parallel and threaded.

Identified impact

(i.e. Internal object changes, limited interface changes, public API change, or a list of specific applications impacted)

Testing is less useful.

[roystgnr]

Even on a 1D mesh, setup subdomain count would fail on partitionings where the partition boundary happens to align exactly with a subdomain boundary, I think - then there would be no switch between subdomains within the element iteration on any single processor.

I think the subdomain count was the only obvious failure I saw, though. Perhaps a short-term partial fix would be to make that optional, then run parallel tests with it disabled?

[permcody]

@aeslaughter - was hoping to find a quick and dirty way to prevent regressions inside of MOOSE where these virtual methods ended up getting called extra times (like maybe through a copy'n'paste bug that would do setup multiple times in a single location). I believe this test object was the result of fixing just such a bug. We might have to go back to the exact reason it was added and think more critically about how a future bug could be prevented. Clearly this isn't working...