Document all dummy v3 endpoint implementations

[georgethebeatle]

Background

We know that some of the v3 endpoints in Korifi are dummies that return hardcoded content. These are leftovers from the early days, when certain short-cuts were taken in order to enable the cf push funcionality sooner. However we should consider fixing them to achieve better API compatibility.

What to do

Go over Korifi's http handlers and look for stuff that is hardcoded or implemented in an overly-simplistic way and open issues for every such endopint

Here are some examples:

• korifi/api/handlers/oauth.go

  Line 32 in e43410e

  tokenString, err := token.SignedString([]byte("not-a-real-secret"))

  - here a token is hard-coded

• korifi/api/handlers/app.go

  Line 679 in e43410e

  func (h *App) getAppFeature(r *http.Request) (*routing.Response, error) {

  - here the implementation is overly simplistic

• korifi/api/presenter/buildpack.go

  Lines 34 to 40 in e43410e

  	Enabled: true,
  	Locked: false,
  	Metadata: Metadata{
  	Labels: map[string]string{},
  	Annotations: map[string]string{},
  	},
  	Links: map[string]Link{},

  - here a part of the resource response is hardcoded, so it is potentilly unused

For each of these simplistic implementations we should find out

• Can we drop them
• What use cases do they enable
• What use cases do they block (by not providing the complete implementation as specified by the api spec)

This context will be important for determining the priority of the resulting stories