reset_memory -> restore_original_nonzero_pattern

[lindsayad]

I also added a pretty important comment to the doxygen string. This reflects what happens in the PETSc implementation. I now have some concern about the method name ... a name like reset_memory makes me think that there's no way something like a no-op could happen. Perhaps a name like restore_(original_)nonzero_pattern would be better? Would this still conceptually allow its use for hash table based memory allocation? I think so since resetting/clearing the hash table restores the original sparsity pattern ... that pattern being whatever you want it to be

[moosebuild]

Job Coverage, step Generate coverage on 3b194d9 wanted to post the following:

Coverage

	047a4c	#4115 3b194d
	Total	Total	+/-	New
Rate	63.32%	63.32%	-0.00%	0.00%
Hits	74333	74333	-	0
Misses	43051	43056	+5	7

Diff coverage report

Full coverage report

Warnings

• New new line coverage rate 0.00% is less than the suggested 90.0%

This comment will be updated on new commits.

[jwpeterson]

Perhaps a name like restore_(original_)nonzero_pattern would be better?

Definitely sounds better to me... in my mind for a SparseMatrix there's the memory associated with the sparsity pattern, and the memory associated with the matrix "values" (although this might not actually match reality) so I would find a reset_memory() API a bit ambiguous on first glance, whereas your other suggestion is not ambiguous at all.

[lindsayad]

Will do. I'm converting this to draft because there are upstream changes to PETSc that I need to make for the work here

[lindsayad]

The Mac ARM test target is pretty obnoxious

[lindsayad]

We are not going to change the API in PETSc so I can remove the WIP draft label from this. Instead we are going to honor the documentation of MatResetPreallocation. https://gitlab.com/petsc/petsc/-/merge_requests/8236