Boundary LF Integrators fast assembly minor bug

[stefanhenneking]

#4027 resolved a seg fault issue in fast assembly of a boundary lf integrator that occurred when a proc in a ParMesh does not have any boundary element. The fix in #4027 (causing procs w/o boundary elements to simply return) resolves most cases; however, for some cases, the fix in #4027 is not sufficient. For example, if EnsureNodes() was not previously called for the ParMesh, then the following calling sequence now ends in a deadlock due to ParMesh::SetCurvature attempting to create a new ParFiniteElementSpace which requires all procs of the ParMesh (not just the ones owning boundary elements of the ParMesh).

BoundaryLFIntegrator::AssembleDevice
--> BLFEvalAssemble
--> Mesh::GetFaceGeometricFactors
--> Mesh::EnsureNodes
--> ParMesh::SetCurvature
--> new ParFiniteElementSpace

Here are two possible fixes for this issue:

• Calling EnsureNodes in BoundaryLFIntegrator::AssembleDevice before checking fes.GetNBE() == 0 (or calling EnsureNodes in LinearFormExtension::Assemble)
• Not using the particular fix from Boundary LF Integrators fast assembly bug fix #4027 that returns if fes.GetNBE() == 0 but instead making BoundaryLFIntegrator::AssembleDevice, BoundaryNormalLFIntegrator::AssembleDevice, etc. safe for procs that don't have any boundary elements.

Which one is preferable comes perhaps down to what MFEM internally assumes when calling functions on ParMesh. The first fix solves the particular issue at hand but since BoundaryLFIntegrator::AssembleDevice etc. still call ParMesh functions from only a subset of ParMesh procs, it could lead to issues in the future if those ParMesh functions are changed and (reasonably) assume all procs that are part of the ParMesh are calling a function (not just the ones owning boundary elements of that mesh).