This is very proof-of-concept currently, but wanted to put the code up
to get initial feedback/ideas. Here's the gist:

  * I define 3 abstract subtypes of `Layer` in the Layers module:
  `InitialLayer`, `RequestLayer`, and `ConnectionLayer`; these
  correspond to the types of arguments the layer would receive when
  overloading `request`; `InitialLayer` => `request(method, url,
  headers, body), `RequestLayer` => `request(url, req, body)`, and
  `ConnectionLayer` => `request(io, req, body)`. I feel like these are
  useful abstract types to help distinguish the different _kinds_ of
  layers based on the arguments they receive in different parts of the
  overall stack. I feel like it hopefully also solves the "how do I
  insert my layer in the appropriate level of the stack" because you
  just pick which abstract layer to subtype
  * Custom layers are then required to:
    * be concrete types
    * must subtype one of the 3 abstract layer types mentioned
    * must have a constructor of the form: `Layer(next::Layer; kw...)
    * must have a field to store the `next::Layer` argument
    * must overload: `request(x::MyLayer, args...; kw...)` where `args`
    will depend on which abstract layer `MyLayer` subtypes
    * in the overloaded `request` method, it must, at some point, call
    `request(layer.next, args...; kw...)` to move to the next layer in
    the stack
    * the final requirement is the custom layer must overload
    `Layers.keywordforlayer(::Val{:kw}) = MyLayer` where `:kw` is a
    keyword argument "hook" or trigger that will result in `MyLayer`
    being inserted into the stack

What I like about this approach so far:
  * It feels more straightforward to define my own custom layer: pick
  which level of the stack I want it in, subtype that abstract layer,
  register a keyword argument that will include my layer, then define my
  own `request` overload; we can define all the current HTTP layers in
  terms of this machinery, custom packages could define their own layers
  and they all are treated just like any HTTP.jl-baked layer
  * It also feels like it would be easier to create my own custom "http
  client"; what I mean by this is that I feel like it's common for API
  packages to basically have their own `AWS.get`/`AWS.post`/`AWS.put`
  wrapper methods that eventually call `HTTP.get`/`HTTP.post`/etc., but
  in between, they're adding custom headers, validating targets, and
  whatever. A lot of that is _like_ a custom layer, but by having your
  own `AWS.get`/`AWS.post` wrapper methods, you can _ensure_ certain
  layers are included; and with this approach that's straightforward
  because they can indeed make their own custom layer as described
  above, and then just ensure every `HTTP.request` call includes the new
  keyword argument to "hook in" their custom layer

Potential downsides:
  * Relying on a global keyword registry; i.e. there's potential for
  clashes if two different packages try to overload
  `Layers.keywordforlayer(::Val{:readtimeout}) = ...`. Whichever package
  is loaded last will "pirate" the keyword arg and overwrite the
  previous method. We could potentially add some extra safety around
  this by having another `clientenv=:default` keyword and then devs
  could overload `Layers.keywordforlayer(::Val{:default},
  ::Val{:readtimeout}) = ...` but that feels a tad icky. I also don't
  expect there to be even dozens of total keywords/layers to process, so
  with that in mind, it also lowers the risk of clash.
  * The previous layer functionality allowed specifying the _exact_
  layer you wanted your custom layer to be inserted before; do we think
  that level of specificity/granularity is really necessary? I'm kind of
  going on a gut feel here that what you really want control over is
  _what kind of args_ your overloaded `request` method will receive and
  that's what my 3 new abstract layer subtypes aim to solve. So you can
  pick 1 of 3 different _general_ layers of where your custom layer gets
  inserted, but don't have control over anything more specific in terms
  of what layer comes before/after
  * One thing I noticed is that the current `stack` function actually
  has some hard-coded logic that checks keyword arguments and
  _conditionally_ will include layers based on the _value_ of the
  keyword arg. We could potentially handle that in the proposed scheme
  by saying that your custom `Layer(next; kw...)` constructor can
  return the `nothing` value, in which case, no layer will be inserted.
  That would give, for example, the `TimeoutLayer` the chance to check
  if the `readtimeout > 0` before returning a `TimeoutLayer` or
  `nothing`

…ng mechanisms

drastically reduce the interface requirements

Co-authored-by: mattBrzezinski <matt.brzezinski@invenia.ca>

Co-authored-by: mattBrzezinski <matt.brzezinski@invenia.ca>

Co-authored-by: mattBrzezinski <matt.brzezinski@invenia.ca>

Co-authored-by: mattBrzezinski <matt.brzezinski@invenia.ca>

Co-authored-by: mattBrzezinski <matt.brzezinski@invenia.ca>