Allow fine-tuning of gRPC server underneath of GrpcContainer
          #1510
        
          
      
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
This changeset is a port of #1454 to
master.Disclaimer
Also, this is just a first of such "porting" PRs. To keep things going, we are going to use the current state of
core-java:master, rather than wait until the whole machinery (ProtoData et al) unwinds in its full blossom. Therefore,config, dependencies and stuff will NOT be updated in scope of "porting".What's Changed
Prior to this changeset, there was no convenient way to set some "native" properties of the gRPC server, which is running underneath Spine's
GrpcContainer.In particular, it is often needed to set the maximum size for the inbound messages. And it was nearly not possible to achieve, other than using a test-only
GrpcContainer.injectServer()method. There is also a number of other configuration endpoints provided by the gRPC'sServerBuilder, which could not be accessed.In this PR, the gRPC's
ServerBuilderAPI becomes exposed like this:So, rather than copying the
ServerBuilder's API inGrpcContainer, the direct access to the builder is provided. That will allow to be always up-to-date with the configuration capabilities of the gRPCServer, rather than copying and chasing their API in the gRPC releases to come.However, as of this PR, the
GrpcContainer.Builder.withServer(...)method is marked as@Experimental. The reason is that the "native"ServerBuilderAPI allows to perform some destructive actions. Therefore, the decision to expose it as-is is not yet final.