enhance(log)!: do not return log object for POST and PUT requests

[ecrupper]

Sort of a revert of #865 but this PR goes further and simply does not bother returning the log object on a successful POST or PUT.

I did a little bit of research on general HTTP practices, and it appears that this question of returning data on 200 and 201 codes is pretty much context-driven. Given that CreateStepLog + CreateServiceLog arguably shouldn't exist for user access and UpdateStepLog + UpdateServiceLog are locked behind worker permissions / platform admins, I think it's safe to say continuously returning the database object is not worth the overhead.

The only logic that utilizes this returned value in the entire codebase is a max-log-size check which can be performed with the in-memory _log value that is appended every second.

Merging this PR would result in downstream changes to the sdk-go, worker, and CLI

[codecov]

Codecov Report

Merging #879 (146f401) into main (ad8d7d7) will increase coverage by 0.02%.
The diff coverage is 62.50%.

❗ Current head 146f401 differs from pull request most recent head ba61fd7. Consider uploading reports for the commit ba61fd7 to get more accurate results

@@            Coverage Diff             @@
##             main     #879      +/-   ##
==========================================
+ Coverage   71.79%   71.82%   +0.02%     
==========================================
  Files         311      311              
  Lines       13024    13026       +2     
==========================================
+ Hits         9351     9356       +5     
+ Misses       3211     3209       -2     
+ Partials      462      461       -1     

Impacted Files	Coverage Δ
database/log/create.go	66.66% <62.50%> (+1.28%)	⬆️
database/log/update.go	66.66% <62.50%> (+1.28%)	⬆️

... and 1 file with indirect coverage changes

[wass3rw3rk]

let's go to the moon 🌕

[cognifloyd]

Returning the log does seem wasteful.

Today, we only use the return to calculate the log's size, so, what if these endpoints returned the size of the log in a header?

[ecrupper]

Today, we only use the return to calculate the log's size, so, what if these endpoints returned the size of the log in a header?

My thought on this was that we already have the data to check size before we make the call to update, and returning really any data would require decompression. I figured just the successful status code would be enough

[jbrockopp]

@ecrupper @wass3rw3rk Do you think we need to mark this as a breaking change?

I'm unsure since the impact is solely scoped to server <-> worker communications.

[ecrupper]

@ecrupper @wass3rw3rk Do you think we need to mark this as a breaking change?

Good idea, even though I doubt it's used at all. I will mark it

[jbrockopp]

LGTM

[cognifloyd]

Today, we only use the return to calculate the log's size, so, what if these endpoints returned the size of the log in a header?

My thought on this was that we already have the data to check size before we make the call to update, and returning really any data would require decompression. I figured just the successful status code would be enough

Ah. I forgot about compression.

This should simplify logging in the worker slightly, so I'm in favor of this.