Adds Suggested Resource detection based on regex patterns

[JPrevost]

Note: bento staging is connected this the Heroku build associated with this PR if you'd like to see how this works with our existing Suggested Resources intervention.

Why are these changes being introduced:

• LIRS staff and UXWS have both noted that searching for Standards is
  not useful in our system

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/TCO-141

How does this address that need:

• Adds a regex pattern based system that is similar to, but different
  than, SuggestedResources
• These patterns can be used for more than just Standards, so the models
  were made to be more generic in name
• The SuggestedPatterns will be stored in our database, which is a bit
  different than our other regular expression based detectors. These
  feel different enough to warrant this difference as we want to store
  additional metadata about what to display for these types of patterns
  when the other regex patterns use external resources to fetch data.

Document any side effects to this change:

• I'm not confident the naming is ideal

Developer

Ticket(s)

https://mitlibraries.atlassian.net/browse/TCO-###

Accessibility

• ANDI or Wave has been run in accordance to our guide and
  all issues introduced by these changes have been resolved or opened
  as new issues (link to those issues in the Pull Request details above)
• There are no accessibility implications to this change

Documentation

• Project documentation has been updated, and yard output previewed
• No documentation changes are needed

ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Stakeholders

• Stakeholder approval has been confirmed
• Stakeholder approval is not needed

Dependencies and migrations

NO dependencies are updated

YES migrations are included

Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[matt-bernhardt]

I really like the SuggestedPattern feature as you've built it, and think it will combine nicely with SuggestedResource.

I see the tests pass, and the review app seems to respond as expected for standards requests. I have two small requests about some code comments, and a few questions to make sure I'm understanding things correctly. I don't think any of those questions are blocking, an approval, but I wanted to get your thoughts while I'm thinking about these changes.

I've tried to summarize all the line-level comments here - hopefully they're consistent.

Small requests:

• I think we need a comment block on the log_summary method
• There's a reference to SuggestedResources that I think should be updated to SuggestedPattern in a comment block

Questions:

• I'm unable to get a response from the staging app for SuggestedResource records now, like 'hours'. I may not be populating these records correctly, however. Could you take a look at this?
• I'm wondering why we're choosing to only respond with one type of Suggested* response in the (highly unlikely) case where a term might generate a response from both a Suggested Pattern and a Suggested Resource?
• I want to confirm that shortcode is only used for distinguishing SuggestedPattern records among users, and not returned by the API?
• Is it intentional that we aren't incorporating SuggestedPattern records in the Administrate interface?
• Does my concern about seeding a link between the SuggestedPattern detector and the Transactional category make sense? I'm not opposed to it for now while we don't have any other records, but would prefer we back off from this link if we do end up getting non-transactional patterns down the road.
• We're dropping the use of a .map() call in the graphql detectors_type, and I want to make sure this is intentional.

Comments:

• You mentioned not being happy about naming, and I agree when it comes to field names in SuggestedPattern. I'm not sure I can come up with better, however.

[JPrevost]

@matt-bernhardt I believe I've addressed your requested changes. Can you please take another look? Thanks

[matt-bernhardt]

Thanks for answering my questions, and addressing the concerns where they made sense to you. This looks good, and should be a solid feature for the application. Thanks!