governance: use concurrent build

[TalDerei]

Describe your changes

uses concurrent build for governance proposals

Issue ticket number and link

Checklist before requesting a review

• I have added guiding text to explain how a reviewer should test these changes.

• If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

[TalDerei]

Is this true? also general question, why is this logic embedded in the top-level action handler?

[conorsch]

We can switch from .build() to .build_concurrent() without introducing an expect(). Let's be cautious about introducing changes to how errors are handled.

[conorsch]

Looks sound, although I'm tagging in @erwanor for confirmation on consensus implications. My asks are:

1. target the protocol/lqt_support feature branch, as described in Tracking issue: LQT #5010
2. don't introduce an expect if we can avoid it

In the meantime I'm tagging this as consensus-breaking out of caution.

[conorsch]

We can switch from .build() to .build_concurrent() without introducing an expect(). Let's be cautious about introducing changes to how errors are handled.

[erwanor]

We typically use the serial build method in action handlers. I don't think we should change anything in the action handlers without a motivation why. It's an easy source of divergence. Here, it might make sense, but we have to be conservative and extremely deliberate with AHs, so closing for now so we can focus on other things.