Optimizer: Parallel gradient/opt point evaluations

[PaulTalbot-INL]

---

Issue Description

What did you expect to see happen?

@crisrab requests that when a new potential opt point is found, we immediately start submitting its evaluation neighbors as well.

What did you see instead?

Currently the optimizer bottlenecks on the evaluation of the new opt point.

Do you have a suggested fix for the development team?

These can be evaluated in parallel, but care should be taken to free up resources in the event a potential opt point proves undesirable and its gradient evaluations are no longer needed.

---

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or improvement?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

---

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
• 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
• 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

[PaulTalbot-INL]

Approved for development, possibly in conjunction with #305.

[alfoa]

Approved for closure via PR #818 .