Add HTTP Deprecation header to legacy REST endpoints

[aaronc]

This will make it easier for users transitioning to stargate. The header should link to documentation on upgrading.

See https://tools.ietf.org/id/draft-dalal-deprecation-header-01.html

We may additionally want to consider Sunset (https://tools.ietf.org/html/rfc8594) and or Warning (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Warning) headers.

[clevinson]

Does deprecation imply that an endpoint currently functions as expected? I ask because I don't think this is the case for all endpoints (particularly the GET /txs endpoint). In my understanding (from this discord thread), we actually do break client expectations here, in that GET /txs/TX_HASH will not work for any transactions created with SIGN_MODE_DIRECT, namely all tx's created via CLI.

I wonder if we need (separately from this issue), a better solution to the above problem. Or at least we should make sure to be explicit in our documentation about what we mean by deprecated here.

Update: Added #7639 to track this

[alexanderbez]

Does deprecation imply that an endpoint currently functions as expected?

Yes, specifically the functionality remains unchanged and non-breaking. However, this is specific to a given context. Namely, yes, the endpoints will work as expected assuming you work with legacy data (e.g. amino-encoded txs). If you attempt to use this endpoint with data built upon new functionality, you really don't get any guarantees towards backwards compatibility.

In such a case, explorers should use these endpoints wisely, where they should strive to use the new endpoints where possible.