refactor(DA): syncing sampling types with spec

[andrussal]

1. What does this PR implement?

Naming in code and in specification aren’t 100% in sync. This PR should help to bridge this gap.

---

I am not sure how deep this should go. For example, in API we have the change: column_idx=>share_idx. Should this be done everywhere or only places that are visible to API callers?

2. Does the code have enough context to be clearly understood?

Yes

3. Who are the specification authors and who is accountable for this PR?

@andrussal

4. Is the specification accurate and complete?

N/A

5. Does the implementation introduce changes in the specification?

N/A

Checklist

• 1. Description added.
• 2. Context and links to Specification document(s) added.
• 3. Main contact(s) (developers and specification authors) added
• 4. Implementation and Specification are 100% in sync including changes. This is critical.
• 5. Link PR to a specific milestone.

[danielSanchezQ]

I am not sure how deep this should go. For example, in API we have the change: column_idx=>share_idx. Should this be done everywhere or only places that are visible to API callers?

Everywhere not just API. Also the struct names that are not on pair, for example:

DABlob => DAShare
DALightBlob => DALightShare
DASharedCommitments => DASharesCommitments

This ones are the one on top of my head at the moment.

[andrussal]

I am not sure how deep this should go. For example, in API we have the change: column_idx=>share_idx. Should this be done everywhere or only places that are visible to API callers?

Everywhere not just API. Also the struct names that are not on pair, for example:

DABlob => DAShare
DALightBlob => DALightShare
DASharedCommitments => DASharesCommitments

This ones are the one on top of my head at the moment.

So I went all the way and number of files looks scary. But probably better get all done at once.

[danielSanchezQ]

It had to be done. Thanks a lot!