Early deprecate functions in DoFTools

[peterrum]

... many functions already return the IndexSets directly.

[kronbichler]

I am not particularly happy about the incompatibility caused by this change. Even though this is only an early deprecation, we will soon get tons of warnings and then error for almost every single deal.II program that uses MPI. I see the point in terms of some other functions in DoFTools, so the interface makes sense and I support it. But I reserve myself against the early deprecation warning already at this stage: I think it should come only when we have gone through all functions with similar interfaces (uniformly return things computed inside function). I think one of the worst things we can do to our users is to randomly deprecate some of the functions for every release, rather than providing a (somewhat) uniform solution which covers most places.

[peterrum]

I am not particularly happy about the incompatibility caused by this change. Even though this is only an early deprecation, we will soon get tons of warnings and then error for almost every single deal.II program that uses MPI. I see the point in terms of some other functions in DoFTools, so the interface makes sense and I support it. But I reserve myself against the early deprecation warning already at this stage: I think it should come only when we have gone through all functions with similar interfaces (uniformly return things computed inside function). I think one of the worst things we can do to our users is to randomly deprecate some of the functions for every release, rather than providing a (somewhat) uniform solution which covers most places.

I have dropped the pragma but would suggest to keep the comment regarding deprecation. Is that fine?

[kronbichler]

I think in this place the regular RVO will probably not help the change will give rise to (very slightly) slower code than we had before, as we need to call the operator= here from the temporary object. This is different from the case in step-18 you made above where RVO eliminates the copy (on sane compilers).

I think this is justified for a cheap object like IndexSet given the interface uniformity it brings us. Furthermore, I believe we should at some point make the locally_relevant_dofs a member variable of the DoFHandler, given how often we set up and use these objects and how little memory they consume in the grand scheme of things. Then this gets even more clear that we should do it. But I do not think the case is necessarily as low for all functions that merely fill something, so we might need to make a case-by-case decision.

[bangerth]

See also #11896.

[bangerth]

Separately, the cost of the move assignment is surely immeasurable compared to the cost of building the object. I'm very much in favor of the new interface.

[bangerth]

Yes, nice. I like these functions a lot better and had wanted to make this change myself for a long time. Thanks for beating me to it!