replace a few simple, unambiguous uses of full

[Sacha0]

Another small step towards deprecation of full. Ref. #12153, #12251, #18850, and linked threads. Best!

[andreasnoack]

Oops. Tridiagonal is now parametric so this is actually now unambiguous anymore. Unwrapping the Tridiagonal matrix could depend on what kind of vectors are wrapped. As discussed during the triage a month ago, the name full might not be appropriate but having a generic function for this instead of explicitly using types might be generally useful.

[Sacha0]

Oops. Tridiagonal is now parametric so this is actually now unambiguous anymore. Unwrapping the Tridiagonal matrix could depend on what kind of vectors are wrapped.

Could you expand? To my knowledge, full on Tridiagonal has only ever meant convert(Array, ...)? Thanks!

[Sacha0]

As discussed during the triage a month ago, the name full might not be appropriate but having a generic function for this instead of explicitly using types might be generally useful.

Yes, absolutely :). The plan I've been whittling away at is: (1) eliminate all remaining simple, unambiguous uses of full (which this pull request completes I believe); (2) eliminate all remaining not-so-simple uses of full that do not require the "lessspecial(...)" mechanism; and then (3) sketch an implementation of the "lessspecial(...)" mechanism and downstream replacements of full, then see how things look. Thoughts? Best! (Ref. #23270.)

[andreasnoack]

Could you expand? To my knowledge, full on Tridiagonal has only ever meant convert(Array, ...)?

I think this was an oversight when Tridiagonal was made parametric. If the vectors are distributed then the result of full should probably be a distributed matrix. I don't think anything in this PR has to change, though. At least not now.