[VEN-2846]: Add SolvBTC market

[kkirka]

This PR adds SolvBTC market to Venus Core (Legacy) pool on BNB mainnet. This PR also contains scripts in the framework to check risk parameters in legacy pool.

[chechu]

Why don't we use the address from the npm package in this case (as we are doing for bsctestnet)? Anyway, I'm not sure if should add to this file the ACM address, because the framework doesn't use it. We could simply define this address in the VIP's where we need it. I think that is the general rule

[kkirka]

Why don't we use the address from the npm package in this case

Address casing is incorrect in the governance repo (it's all lowercase there), I'll make a PR to change that

I'm not sure if should add to this file the ACM address, because the framework doesn't use it

I think the framework shoud use it, it's one of our main contracts and its address is unlikely to change in future. The direction we seem to be going with the framework is to offload more responsibilities to it (e.g. it already checks risk params and market configuration). It could also check ownership / access controls at some point. I can add the corresponding checks (i.e. move

vips/simulations/vip-400/bsctestnet.ts

Lines 50 to 56 in 3a001ba

	it("has correct owner", async () => {
	expect(await vToken.admin()).to.equal(NORMAL_TIMELOCK);
	});
	it("has correct ACM", async () => {
	expect(await vToken.accessControlManager()).to.equal(ACCESS_CONTROL_MANAGER);
	});

to the framework).

I think that is the general rule

Unrelated to all of the above, I think we should discuss this further. It's true that at some point we decided to use hardcoded addresses in VIPs. However, IMO, with more and more networks and deployments the PR reviews become quite time consuming and error-prone – we need to manually check every address, and the more addresses we have hardcoded, the easier it is to miss a mistake in one of them. I think there should be a better approach here (maybe something along the lines of what I mentioned in this thread). If we could check the deployment commit hash rather than all the addresses during the reviews, this would simplify things and make errors less probable.