Implemented a fix for the share price accuracy issue

[jalextowle]

Fixes: #697, #698.

This PR implements a poor man's solution to the problem that we've noticed recently where the base proceeds for longs and shorts closing at maturity are greater by several thousand wei than we'd expect them to be. After closer inspection, the underlying cause of these issues is our use of a sharePrice computed as totalAssets.divDown(totalShares). This conflicts with the accounting done by our yield sources where they will convert from shares to assets with shares.mulDivDown(totalAssets, totalShares).

One solution to this problem would be to rip out our current use of share price and use _convertToShares and _convertToAssets functions tailored to each yield source that could perform a mulDivDown if appropriate. The problem with this kind of change is that it is very invasive and would require the reworking of essentially all of our accounting logic. This is how we should think about the problem when we get a chance to re-write Hyperdrive (perhaps in Hyperdrive V2).

For now, a more expedient solution is to take the base amount implied by the amount of _shares passed into _withdraw as base reality and use this to calculate the amount of shares that need to be removed from the yield source to remove this base amount. Doing the accounting this way ensures that our invariants around the proceeds of matured longs and shorts aren't violated, but it comes with some quirks. One potential issue that this introduces is that the amount of shares removed from the yield source may not be exactly equal to the amount of shares removed from (or added to) the pool's share reserves. In my opinion, this is acceptable since we calculate the share reserves delta consistently using the pool's share price, and the new approach of clamping the proceeds is just an error correction done at the end of the calculation.

[github-actions]

Hyperdrive Gas Benchmark

Benchmark suite	Current: e00b9c9	Previous: 1ad1045	Deviation	Status
addLiquidity: min	1600 gas	1600 gas	0%	🟰
addLiquidity: avg	65250 gas	64846 gas	0.6230%	🚨
addLiquidity: max	275113 gas	275068 gas	0.0164%	🚨
checkpoint: min	1150 gas	1150 gas	0%	🟰
checkpoint: avg	47790 gas	47760 gas	0.0628%	🚨
checkpoint: max	190992 gas	190992 gas	0%	🟰
closeLong: min	1558 gas	1558 gas	0%	🟰
closeLong: avg	28079 gas	27582 gas	1.8019%	🚨
closeLong: max	152053 gas	150993 gas	0.7020%	🚨
closeShort: min	1549 gas	1549 gas	0%	🟰
closeShort: avg	29819 gas	30013 gas	-0.6464%	✅
closeShort: max	147421 gas	147229 gas	0.1304%	🚨
initialize: min	1538 gas	1538 gas	0%	🟰
initialize: avg	213159 gas	213117 gas	0.0197%	🚨
initialize: max	254817 gas	254775 gas	0.0165%	🚨
openLong: min	1487 gas	1487 gas	0%	🟰
openLong: avg	50378 gas	50277 gas	0.2009%	🚨
openLong: max	185024 gas	184902 gas	0.0660%	🚨
openShort: min	1608 gas	1608 gas	0%	🟰
openShort: avg	49607 gas	49540 gas	0.1352%	🚨
openShort: max	179974 gas	179863 gas	0.0617%	🚨
redeemWithdrawalShares: min	1575 gas	1575 gas	0%	🟰
redeemWithdrawalShares: avg	20240 gas	20044 gas	0.9778%	🚨
redeemWithdrawalShares: max	106163 gas	105972 gas	0.1802%	🚨
removeLiquidity: min	1639 gas	1639 gas	0%	🟰
removeLiquidity: avg	150302 gas	149236 gas	0.7143%	🚨
removeLiquidity: max	323757 gas	323566 gas	0.0590%	🚨

This comment was automatically generated by workflow using github-action-benchmark.

[coveralls]

coverage: 95.183% (+0.01%) from 95.169%
when pulling e00b9c9 on jalextowle/feature/share-price-accuracy
into 1ad1045 on main.

[jrhea]

Lgtm. Just a nit in a comment for you to fix.

fwiw, this reduces the delta reported in this issue

#697 (comment)

from 17386 to 2 wei.

I do have a comment about what you wrote in the PR description:

One potential issue that this introduces is that the amount of shares removed from the yield source may not be exactly equal to the amount of shares removed from (or added to) the pool's share reserves.

We already had this issue where the accounting was off. The way it was before, the calculate proceeds didn't match the amount of proceeds withdrawn from the yield source. This seems to have reduced the discrepancy though.