newaddr: various fixes for msggen and docs

[daywalker90]

There were various occurences of p2sh-segwit still left in msggen, tests and documentation. So i removed them. I also updated some documentation files to reflect the current state of newaddr.

Is it problematic that the values in message NewaddrResponse changed?

Fixes: #6996
Replaces: #7146

[daywalker90]

So previously when generating cln-rpc's model.rs we would just count from 0 upwards for enum fields and it somehow worked until i start removing fields and want to preserve backward compatibility. Now i added a commit where we lookup .msggen.json for the field numbers for model.rs whenever we can find them. If not we go back to simple counting. Happy to hear your feedback.

[daywalker90]

this also found another wrong assigment in GetinfoBindingType btw

[cdecker]

Yeah, we haven't removed fields so far, hence we never had a confirmation it'd be assigning stable field numbers. It seems you are hitting a couple of new and untested scenarios. Apologies for not having tried some of these before, and thanks for the incredible help 🙏

[daywalker90]

had to add another check for an edge case that would cause problems in #7218

[daywalker90]

added explicit numbering of rust enums

[cdecker]

I think I found one place where we are still just iterating numbers rather than picking them from the .mssggen.json file in grpc.py, otherwise this is very much good to go 👍

[daywalker90]

rebased and fixed

[daywalker90]

I think I found one place where we are still just iterating numbers rather than picking them from the .mssggen.json file in grpc.py, otherwise this is very much good to go 👍

Where in grpc.py? enums for node.proto get sorted. For convert.rs sorting should be irrelevant, right?

[cdecker]

I think I found one place where we are still just iterating numbers rather than picking them from the .mssggen.json file in grpc.py, otherwise this is very much good to go 👍

Where in grpc.py? enums for node.proto get sorted. For convert.rs sorting should be irrelevant, right?

I meant the 1 that should be a 3 in the previous comment :-)

[cdecker]

ACK a227b279ba26e3ff0d81a22247a7bdb2f7ea8aae

[cdecker]

Technically we could leave these in, as a trace for future reference, so we don't end up reusing the same number for a new enum variant. But I'll merge this as is, since that's out of scope for this PR.