Cancel allocation request and BlobberChallenge object - improve performance

[Sriep]

https://github.com/0chain/0chain/issues/533 should improve cancelAllocationRequest benchmark performance. This should be enough for finalize_allocation, but cancel_allocation had another problem due to its need to handle open challenges.

The second problem is in canceledPassRates. In particular unmarshalling blobber challenges with 100 challenges seems to be take around 5ms per blobber BlobberChallenge.Decode

func (sn *BlobberChallenge) Decode(input []byte) error {
	err := json.Unmarshal(input, sn)
	if err != nil {
		return err
	}

[Sriep]

This looks like we should focus on improving the BlobberChallenge object and its array of StorageChallenger objects. Test suggest each StorageChallenge is taking tens of microseconds to unmarshal, so an array of 100 of these in 20 different BlobberChallenge objects and its taking too long.

Cancel allocation uses the BlobberChallenge object to tell the number of failed and open challenges. For this, It only accesses the StorageChallenge.Created and Response field in each item in the BloberChallenge.Challenges array.

We could look at keeping this information at a separate MPT location and avoid unmarsahlling the whole object.

[Sriep]

Fixing the BlobberChallenge issue we reveal the extendOffer block.

		var sps = []*stakePool{}
		for _, d := range alloc.BlobberDetails {
			var sp *stakePool
			if sp, err = sc.getStakePool(d.BlobberID, balances); err != nil {
				return "", common.NewError("fini_alloc_failed",
					"can't get stake pool of "+d.BlobberID+": "+err.Error())
			}
			if err = sp.extendOffer(alloc, d); err != nil {
				return "", common.NewError("alloc_cacnel_failed",
					"removing stake pool offer for "+d.BlobberID+": "+err.Error())
			}
			sps = append(sps, sp)
		}

This is taking around 50ms, too long, and is the same code as in updateallocation https://github.com/0chain/0chain/issues/568#issuecomment-937654641 and can be addressed the same way. I suggest using go routines and channels as a first approch.

[ma2b0043]

@Sriep when can we expect to close this issue?