feat!: Remove backend solvable methods from the interface and solve them in ACVM

[guipublic]

Related issue(s)

(If it does not already exist, first create a GitHub issue that describes the problem this Pull Request (PR) solves before creating the PR and link it here.)

Resolves (link to issue)

Description

Summary of changes

Use ACVM instead of calling the backend for solving blackbox functions, for the bb functions which do not use barretenberg for solving (the low hanging fruits).

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Additional context

Once this PR is merged, I will remove the related solve traits from pwg so that backends do not need to implement these solvers.

[TomAFrench]

Much happier with this compared to original proposal as now we've defined a proper interface. This PR is leaving a lot of dead code on the PWG trait however which needs to be cleaned up.

[TomAFrench]

This PR is still leaving dead code on the PartialWitnessGenerator trait.

[guipublic]

Yes, the idea is to remove this in another PR when this one is merged, we will be able to remove corresponding solves in the backend safely since they will not be called after this PR is merged.

[phated]

I think we could rename the PR to feat!: Solve blackbox functions in ACVM instead of backends and then remove the functions from the PWG trait in this same PR. It'd communicate to implementors accurately, as this chore would be excluded from the changelog currently.

[guipublic]

Since we want to have small PRs, I think it makes sense to have this one which does not call the backend and implement the solve methods, but does not break anything (and so it is a chore), and then have another one which will be a feat! and will break the interface, but it will only do that. This way there is no confusion between implementing the solvers and modifying the PWG trait.

[TomAFrench]

Agreed with renaming PR, I don't really see the logic in doing this in two steps. We should only have one implementation of the black box functions in use at any one time.

[phated]

I don't think this PR is non-breaking. If a backend was relying on their implementation of backend.schnorr_verify but you switch it in this PR, then they are broken. If we remove the PWG functions in the same PR, it is very clear that there isn't 2 separate implementations.

[guipublic]

If a backend was relying on their implementation of backend.schnorr_verify but you switch it in this PR, then they are broken

No they are not be broken if I switch-in this PR, the schnorr verification should work for both implementations, if not that means their implementation was already broken.

[TomAFrench]

Another example would be HashToField128Security, if a backend were using a hash function other than blake2s then this would be breaking.

[kevaundray]

If a backend was not doing the correct behavior for functions like hash_to_field etc, then I think thats on them -- and us for not having a spec.

I'm impartial as to this PR being breaking, but we should not release a version without the accompanying breaking change which removes the duplicates.