MeshBase move constructor can't be safely defaulted

[lindsayad]

This is because of the way we construct the BoundaryInfo member. Using
the default move constructor, our BoundaryInfo in the move-constructed
object will have an invalid reference to its _mesh member after the other_mesh
is destructed.

[jwpeterson]

Hmm yeah I see the problem, but I hate having yet another copy/paste maintenance issue in mesh_base.C to go along with the copy constructor. Is there any way that we can just delete the move constructor for now? I suppose if we found that we were spending a lot of time copying meshes we could look into implementing it...

[jwpeterson]

Though the issues with #2710 means that we won't be able to store Mesh objects directly in std::vectors without this... if that is important it could also warrant a non-default implementation of course but IMO holding vectors of unique_ptrs is usually going to be a good workaround for non-MoveInsertable objects.

[lindsayad]

Ugh I suppose I can just continue to operate with unique_ptr instead of instances. I will just delete the move constructor as recommended

[jwpeterson]

Well I'm OK either way. If you promise to maintain the hand-coded MeshBase move ctor :)

[roystgnr]

I also vote for @lindsayad to be in charge of maintaining the move constructor.

[lindsayad]

If I come up with a convincing reason to have a move constructor beyond programming laziness (which would actually incur real run-time expense since moving a unique_ptr is trivial), then I will add the implementation back

[jwpeterson]

This definitely fixes potential bugs, so seems like it should be cherry-picked onto 1.6.0.

[lindsayad]

merge conflict sad. Oooo I keep the approval though! I like that