proto: deprecate duplicate string fields in requests

[guggero]

Follow-up for #3650.

With this PR we deprecate fields that have been specifically added to
to work around a bug in the gRPC/REST gateway that didn't allow bytes
fields to be encoded in REST requests.
That bug has now been fixed so the fields are no longer required.
To make it more clear how bytes fields have to be used in REST,
comments have been added to all those fields.

[joostjager]

I think you looked for all the duplicated fields in this PR? I am wondering, what to do with the fields for which there is only a string field, which should really have been bytes? There are for example numerous pubkey fields.

[joostjager]

This makes the whole oneof redundant. But maybe that removal should be done in a second step?

[guggero]

I removed the deprecation from this field again. This is the case @Roasbeef mentioned where it might be useful for the users to be able to just pass in the string representation of a TXID that they get from a previous output and don't need to byte-reverse it before feeding it into the RPC/REST call. So the oneof can also remain.

[guggero]

I removed the deprecation from the TXID field. There are only 5 deprecations in this PR now, all of them are duplicates and very likely introduced to work around the bug that is now fixed.
In my opinion we should not look at any other string fields that could be sent as bytes just yet. Changing all of those would introduce too many compatibility issues between versions.

[wpaulino]

I removed the deprecation from this field again. This is the case @Roasbeef mentioned where it might be useful for the users to be able to just pass in the string representation of a TXID that they get from a previous output and don't need to byte-reverse it before feeding it into the RPC/REST call. So the oneof can also remain.

Seems more like an inconsistency with our API then? As long as we accept and return them in the same format, there's no need to keep the string field.

[wpaulino]

Nit: there's a double space after the period here and in some other cases below that would be reflected in the API documentation.

[guggero]

The double space was used in several places so I thought that was a style we wanted to use for some reason. But I removed all of them now.

[guggero]

There are quite a few inconsistencies in the API, especially around the TXIDs.
For example, in the output the channel point is sometimes a string (<txid>:<idx>) and sometimes of type ChannelPoint. Which is in turn more or less the same as OutPoint.
Because this grew over time, there are many things that could be made cleaner.
Maybe we should do a massive API overhaul when we know how to proceed with the custom jsonpb library? It would be nice if we could switch everything over to hex encoding instead of base64 in REST.
But that sounds more like something for 0.10 or even 0.11.

[wpaulino]

Because this grew over time, there are many things that could be made cleaner.
Maybe we should do a massive API overhaul when we know how to proceed with the custom jsonpb library?

Definitely, sounds good to me.