Better Cache Control for API requests

[KrishnaPG]

Not familiar with GO language, so not sure if this is being already handled, but the below notes are based on what is being seen in the LakeFS UI for api request results.

The LakeFS api responses can benefit from optimal cache control with below considerations:

1. The commits, tags, releases etc. historical data is mostly immutable. (Both their file listing as well as the file content)
2. The "active" branches data may not be cached, but can benefit from eTag and last-modified checks

For example:

• the routes such as /repositories/repo1/commits/<id> can be cached (immutable?), but there does not seem to be any cache header present in the response (screenshot below)
• the file content data from those "old commits" can also be cached "forever" (immutable)
• dynamic file content on "active" branch can benefit from HTTP 304 Not Modified status code responses (instead of sending full content back)

This can vastly improve the performance for the APIs and Web-UI especially as the system grows in number of commits. Please consider adding these. 

[nopcoder]

@treeverse/product please prioritize.